FlowDrop Workflow Specification 1.0-draft

loop_back is a value on a ForEach node and a bare signal everywhere else

The rule

Normative: this is the rule
  1. On a ForEach node the reserved loop_back input carries the round's item result, standing in for an explicit item_result input wherever that is absent.
  2. On every other node type the reserved loop_back input is a re-entry signal only: the value is delivered on the port and read by nobody, since a node with no iteration state has nothing to fold it into.
  3. A node type that wants the value declares its own port for it, which is exactly what suppresses the reserved injection.

What it means

loop_back is not one signal with two names. On a ForEach node it carries data: whatever arrives on it stands in for the round's item_result when that port is not otherwise filled, so a loop body that only wires its result back to loop_back still folds it in. On every other node type the same port carries nothing readable — a value delivered there is read by nobody, because a node with no iteration state has nothing to fold a result into. A node type that wants the value declares its own port under that name, and that declaration is exactly what stops the reserved, dataless injection.

Example

A ForEach node mid-loop, resumed with a value on loop_back instead of on item_result:

The re-entry input
{"loop_back": "loopback_result"}
What the next round reportsadvanced
{"current_item": "b"}

The loop advances exactly as it would have if the same value had arrived on item_resultloop_back supplied the round's result, not a re-entry signal with no payload.

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-5 · changed in spec 1.0