Skip to main content

Flow Control

What this category is for​

Use flow-control nodes to control timing, split execution, synchronize branches, redirect clients, or terminate execution explicitly.

Node list table​

Node typePurposeKey inputsBranch outputs
delay_nodePauses execution for a configured time.Config delay_msnone
parallel_nodeForks to all outgoing edges concurrently.nonenone (all outgoing edges run)
merge_nodeWaits until all incoming branches complete and emits combined upstream outputs.implicit $predecessor_ids, $upstreamnone
redirect_nodeSends HTTP redirect and ends flow.input url (required), config status (301/302/307/308)none
stop_nodeEnds workflow without sending a response.nonenone

Common patterns​

1) Fan-out then join​

  • parallel_node triggers multiple independent branches (audit write, notification, enrichment)
  • Each branch feeds merge_node
  • Use merge_node.result to build one consolidated downstream payload

2) Rate-limited upstream protection​

  • Insert delay_node before http_request_node for controlled pacing in sensitive integrations
  • Tune delay_ms conservatively and measure latency impact

3) Async side effect after response​

  • response_node (immediate client reply) then side branch to parallel_node and stop_node
  • Useful when client must not wait for non-critical work

4) Redirect-based handoff​

  • condition_node or switch_node -> redirect_node for browser-facing flows (auth handoff, docs relocation)

Common mistakes and how to debug​

  • Merge never runs: merge_node executes only when all incoming predecessors have completed. Check missing edges or branches terminated early.
  • Unexpected cycle error: engine marks visited nodes and fails on revisit. Avoid wiring arbitrary cycles back into already executed nodes. Controlled iteration uses the Loop Node (see Logic And Routing), which runs body nodes per array item—do not confuse with accidental graph cycles.
  • stop_node used in request/response path: it does not send HTTP response. For API endpoints, end with response_node or redirect_node.
  • parallel_node ordering assumptions: branch completion order is non-deterministic. Do not rely on ordering side effects.
  • Redirect URL missing: redirect_node errors when url is empty. Confirm expression resolves to a non-empty string.