FlowDrop Workflow Specification 1.0-draft

A node executed more than once keys its results by occurrence

The rule

Normative: this is the rule
  1. A node's first execution in a run is reported under its bare node identifier; each later execution is reported under {nodeId}:{n}, where n is that node's zero-based count of prior executions in the run, and the payload of a stop raised by the node uses the same key.
  2. Partial results reported for an interrupted run use an equivalent scheme.
  3. Each completed execution is stamped with a higher execution order than the one before it, so a port fed by several sources resolves to the newest execution of a source node: inside a loop, the current round's.

What it means

Only the first execution of a node keeps its bare identifier. Every later execution — a body re-entering a loop — is reported under {nodeId}:{n}, counting from zero, so the second execution is :1 and the third :2, not :2 and :3. A reader who assumes the suffix counts the execution itself, rather than how many came before it, will look for the wrong key.

The same ordering decides what a port sees when several sources feed it: the execution stamped with the highest order wins, which inside a loop means a node reading from an upstream source always gets that source's most recent pass, never a stale one left over from an earlier iteration.

Example

A node that runs three times in one run reports its results under these keys, first pass bare:

Three completed executions of one nodekeyed
["loop_node", "loop_node:1", "loop_node:2"]
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 · SG-8 · changed in spec 1.0