Structure preconditions are checked before anything is planned
The cheapest checks run first, so a workflow that cannot possibly execute is rejected before any graph work happens.
The rule
Normative: this is the rule
- Before any graph is built, compilation checks, in order: the workflow has an identifier; it has at least one node; and then, per node in definition order, that the node has an identifier and that it has a type.
- The first failure refuses compilation, and the failure names which precondition failed and, where the failure is a node's, which node.
What it means
The cheapest checks run first, and in a fixed order: the workflow's own identifier, then whether it has any node at all, then — per node, in definition order — that the node has an identifier and that it has a type. A workflow missing its own identifier is refused before any node is examined at all, whatever shape those nodes are in. Within the per-node pass, the first node in definition order that fails is the one named in the failure; a later node's problems are never reported instead.
Example
{ "nodes": [{ "id": "node1", "type": "text_input" }] }"Workflow must have an ID"The same shape, with an identifier but a node missing its type:
{ "id": "test_workflow", "nodes": [{ "id": "node1" }] }"Node node1 must have a type"The message names the node — node1 — not merely that some node failed.
Rule identifiers are permanent and are never renumbered. Each implementation publishes its own standing against these rules; this specification does not.spec 1.0-draft · CMP-3 · changed in spec 1.0