Break — Input & Output

Signal-based exit: The Break node does not directly jump execution to the Loop's done port. Instead, it signals the loop via a memory flag. The Loop node observes the signal and performs the transition. This design ensures execution flow remains consistent and auditable.

Output Ports

Port	When Triggered	Description
`break`	Immediately when the Break node executes	The break port fires after setting the LoopBreakSignal. You can connect optional cleanup or logging nodes to this port. In most use cases, this port has no connections and execution returns to the Loop node which then fires its done port.

Execution Memory Written by Break

Memory Key	Value	Cleared By
`LoopBreakSignal`	`true`	Cleared by the Loop node after it detects the signal and transitions to the done port

Data Flow After Break

// === Loop iterating over 5 items ===
// Iteration 1 completes normally
// Iteration 2: IfCondition routes to Break node

// === Break node executes on iteration 2 ===
// Sets LoopBreakSignal = true in execution memory
// Fires "break" port (no downstream nodes connected)

// === Loop node detects signal ===
// Clears LoopBreakSignal
// Does NOT start iteration 3, 4, or 5
// Fires "done" port with:
{
  "loop_completed_normally": false,
  "loop_total_items": 5,
  "current_index": 1,       // last executed iteration index
  "current_item": { ... },  // last executed item
  // All variables accumulated during iterations 1 and 2
  // Variables set before break (e.g., breakReason) are available
}

Post-Break Routing in the Done Port

Downstream nodes connected to the Loop's done port can use the loop_completed_normally flag to distinguish between a full successful iteration and an early break exit. A common pattern is to connect an If Condition node immediately after the Loop's done port:

// If Condition after Loop done port:
{
  "condition": "$var.loop_completed_normally === true"
  // true:  → NormalCompletionPath
  // false: → EarlyExitHandlingPath
}

This pattern allows the workflow to take a completely different action depending on whether all items were processed or the loop exited early, without requiring separate workflow branches for each scenario.