FlowDrop Workflow Specification 1.0

A required parameter marked skip skips its node instead of failing it

The exception to CFG-9. A node that was given nothing to work on is left out of the run, the same way an untaken branch is, and the run is not failed by it.

The rule

Normative: this is the rule
  1. This rule applies where a parameter is required, its when_missing flag is skip (CFG-20), and it is missing: no priority supplied it (CFG-4 to CFG-6), as CFG-9 defines missing.
  2. In that case the node MUST NOT be executed.
  3. The node MUST be recorded as skipped, on the same announcements and with the same reason as BR-7 records a skip.
  4. The node MUST NOT be recorded as failed, and the skip MUST NOT fail the run.
  5. Where several required parameters are missing, the node MUST be skipped if any one of them has when_missing skip, whatever the others have: a node that is not executed does not fail.
  6. A key present with a null value counts as supplied (CFG-7), and so does a null effective default: such a parameter is not missing, and its schema decides whether the null is acceptable (CFG-10).

What it means

"Missing" is narrow on purpose. The parameter got nothing from a wire or from the launch, nothing from the author's configuration, and has no default. A null that somebody did send, or that the node type records as its default, was chosen. It is resolved and checked like any other value, and the parameter's schema decides whether it is acceptable (CFG-10).

The skip looks exactly like a BR-7 skip from outside: the same reason on the skip event, the real-time status and the snapshot, and the node counted among the run's skipped nodes. What follows needs no rule of its own. A node that reads from the skipped node never becomes ready (DATA-4), and BR-7's end-of-run sweep records it as skipped too. A node that does not depend on it runs as usual.

BR-7 says a node with no incoming trigger edge is never skipped for want of a trigger. That is about trigger edges only: it does not promise the node runs whatever else happens, and the sweep already covers a node that was ready but never executed.

Example

A workflow with two trigger nodes, on_insert and on_update. A firing of the update trigger supplies only event:on_update:

The initial data the firing deliversdelivered
{ "on_update": { "event": { "ref": "node/42", "changed_fields": ["body"] } } }
The skipped nodes in the run's response metadataskipped
["on_insert", "notify_new_article"]
The run's statuscompleted
"completed"

Why

Recorded under OPEN-21, OPEN-25, OPEN-26, OPEN-42.

Fixtures

Test cases whose outcome this rule decides. A case compares absent, null and empty members exactly; the fixtures README defines each operation. Where a case and the rule disagree, the rule is right.

  • A missing skip parameter skips the node even when another missing parameter would fail it resolve-parameters

    A node that is not executed does not fail; declaration order plays no part.

    {
      "given": {
        "parameters": {
          "b": {
            "schema": {
              "type": "string"
            },
            "connectable": true,
            "exposed": true,
            "configurable": true,
            "required": true
          },
          "a": {
            "schema": {
              "type": "string"
            },
            "connectable": true,
            "exposed": true,
            "configurable": true,
            "required": true,
            "when_missing": "skip"
          }
        }
      },
      "expect": {
        "skipped": true
      }
    }

    fixtures/presence/cfg-skip-beats-fail.json

  • A null default is supplied, so a skip parameter does not skip resolve-parameters
    {
      "given": {
        "parameters": {
          "x": {
            "schema": {
              "type": [
                "string",
                "null"
              ]
            },
            "default": null,
            "required": true,
            "when_missing": "skip",
            "connectable": true,
            "exposed": true,
            "configurable": true
          }
        }
      },
      "expect": {
        "resolved": {
          "x": null
        }
      }
    }

    fixtures/presence/cfg-skip-null-default-is-supplied.json

  • A null is supplied, so a skip parameter does not skip resolve-parameters
    {
      "given": {
        "parameters": {
          "x": {
            "schema": {
              "type": [
                "string",
                "null"
              ]
            },
            "required": true,
            "when_missing": "skip",
            "connectable": true,
            "exposed": true,
            "configurable": true
          }
        },
        "inputs": {
          "x": null
        }
      },
      "expect": {
        "resolved": {
          "x": null
        }
      }
    }

    fixtures/presence/cfg-skip-null-is-supplied.json

  • A required skip parameter nothing supplies skips its node resolve-parameters
    {
      "given": {
        "parameters": {
          "x": {
            "schema": {
              "type": "string"
            },
            "required": true,
            "when_missing": "skip",
            "connectable": true,
            "exposed": true,
            "configurable": true
          }
        }
      },
      "expect": {
        "skipped": true
      }
    }

    fixtures/presence/cfg-skip-when-absent.json

Rule identifiers are permanent and are never renumbered. Each implementation publishes its own standing against these rules; this specification does not.spec 1.0 · CFG-21 · changed in spec 1.0