Skip to content
RunningLake
Contents: Run and automate

BUILDING Parts of this page describe what is not built yet, and each says so.

Parameters

A pipeline can declare parameters, so that one pipeline serves many runs: a day to load, a region to read, a flag to switch a step. A run is started with values for them, and the values are checked against the declaration before anything runs.

No run can be started with values yet: a pipeline that declares a parameter is refused at the start until a plane reports that it can bind them. Declaring, checking and the gate that keeps values out of SQL work now.

Declare parameters

Parameters are a list under spec.parameters in the pipeline’s file, at most 32. Each has a name, a type, and optionally required, a default and a description. The pipeline below declares two, reads them in its SQL, and also shows how a webhook fills them.

apiVersion: runninglake.io/v1alpha1
kind: Pipeline
metadata:
  name: payouts
spec:
  owner:
    team: finance
  routing:
    format: ICEBERG
  parameters:
    - name: day
      type: date
      min: 2020-01-01
      max: 2040-01-01
      required: true
      description: The day whose payouts to load
    - name: region
      type: enum
      values: [us, eu]
      default: us
  triggers:
    webhooks:
      - name: stripe-payout
        parameters:
          day: {from: /data/object/arrival_date}
          region: {value: eu}
        limits: {startsPerHour: 20, activeRuns: 2}
  assets:
    - name: gold.finance.payouts
      sql: select getvariable('day') as day, getvariable('region') as region
      materialization: append
  • A name starts with a lowercase letter and then holds lowercase letters, digits and underscores, up to 63 characters. Names starting rl_ belong to the platform.
  • A default is checked against the type where it is written. A required parameter has no default.
  • Every value in the declaration is text, in the type’s own spelling: default: "0.10", min: "2026-01-01", values: [us, eu]. A number would be rounded by the YAML reader before the gate saw it, so a bare 0.10 or 2026-01-31 is read as the text written.

The types

TypeA value is written
stringAny text.
integerA whole number that fits 64 bits, with no leading zero and no plus sign.
decimalAt most 38 digits, at most 9 of them after the point. The digits are exact: a number is never passed through a floating-point value.
booleantrue or false and nothing else.
dateISO 8601, YYYY-MM-DD.
timestampRFC 3339 with an offset, kept as UTC, with at most six digits of fraction (the engine holds microseconds).
enumExactly one of the listed values.

A value is kept in one canonical spelling, so two spellings of one date are one stored value and one start.

Constraints

  • string takes maxLength (at most 4096) and an anchored pattern, an RE2 expression of at most 256 characters that is matched against the whole value.
  • integer, decimal, date and timestamp take min and max. decimal also takes scale, at most 9.
  • enum takes its values, at most 64.

A parameter that a webhook reads from a request’s body has to be constrained, so that a request cannot size work or name a file with a value nobody bounded. The page on webhooks has the rule.

Read them in SQL

A statement reads a parameter with getvariable('name'), as the pipeline above does. The authoring gate keeps that the only way a value is read, and refuses:

  • getvariable with anything but one plain quoted name that the pipeline declares (or one of the platform’s own variables). A name built with concat is refused, and so is a name spelled in another case, because the engine would read it as the same variable.
  • SET VARIABLE and RESET VARIABLE, anywhere in the SQL, so a statement cannot change a value it was given.
  • Functions that list every variable or run a statement built at run time, because they would walk around the rule above.

The gate is held to the engine itself with a long list of statements, including calls hidden in comments and a SET VARIABLE nested inside another statement.

What a start checks

  • Every value is checked against the declaration, and a name that is not declared is refused. All the values together are at most 64 KiB.
  • A refusal names the parameter and says what is wrong in a sentence chosen from a closed list, such as must be a date written YYYY-MM-DD or must be one of us, eu, and 2 more. It never contains the value or any part of it. The one text the caller typed that a refusal can carry is an undeclared name, cut at 64 characters and quoted.
  • What is kept is the canonical form, with its type and where it came from.

How a value reaches the engine

No byte of a value is ever written into SQL text. A value is checked, kept in canonical form and handed to the engine as a typed variable, so a value that looks like a command is still only data, and a statement that reads it with getvariable gets a date where the declaration says date. A plane that cannot do this is not asked to: a pipeline that declares parameters is refused at the start on a plane that does not report it can bind them, because an engine that does not know about variables reads every getvariable as null and would write wrong rows without saying so.

Where values come from

  • The caller that starts the run.
  • The parameter’s default, when the caller sent no value.
  • A webhook, from the request’s JSON, or from a constant the trigger declares. Webhooks says how.
  • A storage rule, for the platform’s own variables.

The run keeps each value with its type and its source for as long as the next section says. The audit log keeps only a keyed digest of each, under a key that is different for every organisation, so the same value in two organisations does not digest alike, and never the value itself.

How long a run keeps values

Values are cleared seven days after a run ends. The run then keeps each parameter’s name, type and source, and says when it cleared the values, so an empty value on such a run is never a value that was empty. The audit log’s keyed digests are not touched.

The run’s Parameters tab says “cleared” in place of each value and when, and Run again fills in nothing from a run whose values were cleared, so a value you meant to repeat is typed again and never quietly replaced by the default. A repeat of a start that supplied values, sent after they were cleared, is refused as a conflict that says to use a new key, because the values it would be compared with are gone.

Parameters are not secrets

secretRef is reserved and refused: a parameter cannot be a secret yet. A parameter is data: it is kept with the run, and a secret kept there could not be erased from an audit chain once it reached one. A credential belongs in a secret reference, which names where the value lives and never carries it; see Secrets.