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
- This rule applies where a parameter is required, its
when_missingflag isskip(CFG-20), and it is missing: no priority supplied it (CFG-4 to CFG-6), as CFG-9 defines missing. - In that case the node MUST NOT be executed.
- The node MUST be recorded as skipped, on the same announcements and with the same reason as BR-7 records a skip.
- The node MUST NOT be recorded as failed, and the skip MUST NOT fail the run.
- Where several required parameters are missing, the node MUST be skipped if any one of them has
when_missingskip, whatever the others have: a node that is not executed does not fail. - A key present with a
nullvalue counts as supplied (CFG-7), and so does anulleffective default: such a parameter is not missing, and its schema decides whether thenullis 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:
{ "on_update": { "event": { "ref": "node/42", "changed_fields": ["body"] } } }["on_insert", "notify_new_article"]"completed"Why
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 } }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 } } }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 } } }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 } }