Execution Safeguards

Workflows Studio's execution engine has several built-in safeguards that run automatically — you don't configure them, but you may see their effects in Reports and the Progress Path. This page explains the three main ones: loop protection, the stall registry, and sync-block cleanup.

Loop protection

The engine counts how many times each node executes within a request. If a single node executes more than the allowed limit (500 times by default), the engine assumes the workflow is stuck in a runaway cycle and force-completes the request rather than letting it run forever.

• The limit applies per node, per request — a long workflow with many different nodes is unaffected; only a node being re-entered over and over trips it.
• When tripped, the request is marked Completed with an internal flag noting the status was overridden by the engine.
• This is separate from a loop node's own Max Iterations setting (1–500), which bounds For Each and While loops by configuration. Loop protection is the engine-level backstop behind it.

The stall registry

Every node execution is tracked in an internal execution registry that records its status from the moment it's picked up until it finishes. The registry is how the engine detects executions that stopped making progress — for example, when infrastructure is interrupted mid-execution.

When the engine picks up a node whose registry entry says it is still in progress from an earlier attempt, it treats the execution as stalled and responds in two stages:

1. Automatic recovery. The engine attempts to resume the node safely. Nodes that are idempotent or stateless (Action, Function, Decision, Merge, Branch, Update, Mapper, loops, sync blocks, and similar) are re-enqueued for execution after a short delay, with a bounded number of retries. Time-based and user-action nodes first clean up any orphaned reminders or scheduled actions, then re-enqueue.
2. Marked as Blocked. If recovery isn't possible, the node execution is recorded as stalled — shown as Blocked in the request's Progress Path — and the request waits for an admin to intervene.

Sync-block cleanup

Synchronous blocks execute a bounded traversal: a single sync-block run executes at most 120 nodes. If the block hits that limit, or a node inside it fails while the workflow is configured to fail on errors, the engine stops the traversal and cleans up the block's execution state — the per-node visit counts and source-status records for every node in the block are deleted.

This cleanup is what allows the same sync block to run again from a clean slate on the next attempt (for example, when a user re-submits after a failed initiation), instead of nodes being skipped because they appear "already visited" from the failed run.

• If the 120-node limit is exceeded, the sync execution fails with an explicit error identifying the sync block.
• The cleanup covers the whole block — every node between the sync block's start and end markers.