Execution safety net

6

layered defenses against loops and recursion

0

process restarts needed to recover the queue

seconds

to abort a recursion — not minutes, not “never”

10

max nesting levels (configurable)

The problem it solves. You’re building a flow and, while testing it, a Sub Workflow that calls itself (or a badly built iteration) enters an infinite loop. With no defenses, that execution never yields: it holds a worker slot forever and, with a few loops, the queue freezes. The safety net makes sure you never reach that point.

The six defenses

They act in layers: if one doesn’t reach, the next one cuts

1 · Anti-recursion

If a workflow ends up calling itself (A → B → A), Floogos detects it at runtime and aborts with a clear message showing the chain that caused the cycle. No infinite descent.

2 · Depth cap

Sub-workflow nesting is bounded (10 levels by default). Past that limit the execution stops with an explicit error instead of growing without control.

3 · Tree-wide cancellation

The Stop button now halts the children too. Cancelling the execution you see in the editor cuts the whole sub-workflow tree, not just the top level.

4 · Node budget

A count of executed nodes catches cyclic chains (a node pointing backwards) even when the clock hasn’t run out. Past the budget, the execution is marked failed.

5 · Execution deadline

Every execution has an effective time limit. On expiry the engine cuts cleanly between nodes and records the error for diagnosis.

6 · Worker watchdog

The final backstop: if a node never yields, the worker releases its slot on timeout. The queue keeps flowing even if one execution gets stuck — with no process restarts.

How to stop a runaway execution

Three ways, from the simplest to the last-resort backstop

The «Stop» button

In the editor, during a run, the stop control cancels the whole tree. The engine cuts at the next safe point between nodes and marks the instance as cancelled.

It stops itself

Recursion, depth cap, node budget or deadline: any of the four aborts the run on its own, with no intervention, and leaves the reason in the trace.

Automatic watchdog

If none of the above reaches (a node that won’t yield), the worker releases its slot on timeout. No need to touch the infrastructure: the queue never freezes.

Manual runs

A manual run does get queued and does enter the retry queue if a node fails. What an infinite loop never does is fail — that’s why defenses 1–6 cut it from another angle. If you’re debugging and don’t want a broken flow to retry in a backoff loop, a run can be marked not to retry.

On-premise installations only

Environment variables are set on the server where Floogos runs, so they apply to on-premise installations. On Floogos Cloud you don’t have access to them — these values are managed by the Floogos team. If you need one changed for your account, get in touch with support.

Available settings

All with a safe default; tuned via environment variables

Setting	Default	What it controls
SUBWORKFLOW_MAX_DEPTH	10	Maximum sub-workflow nesting levels.
WORKFLOW_MAX_NODE_EXECUTIONS	10000	Node-execution budget per run (catches cycles).
WORKFLOW_MAX_EXECUTION_SEC	—	Maximum execution time for all flows. 0 = no limit.
WORKFLOW_DEFAULT_EXECUTION_SEC	3600	Default maximum time (1 hour) when nothing else is defined.
WORKER_JOB_TIMEOUT_MS	600000	Hard worker timeout (releases the slot).
DLQ_SKIP_MANUAL	false	When on, manual runs don’t retry on failure.

Code nodes

A raw while(true) inside a code node keeps burning CPU even after the worker releases its slot (JavaScript is cooperative). The real defense there is not creating the loop (defenses 2 and 4) plus the CPU/time limit of the isolated sandbox the user code runs in.

Design without fear of loops

The safety net is the backstop, not the plan. The best execution is the one that never runs away: learn to chain sub-workflows without creating cycles.

Sub Workflow best practices →

Keep reading

• How long an execution can run — the time limit, when it gets in the way and how to remove it.
• Sub Workflow — the node that runs another workflow as a step.
• Sub Workflow best practices — when to use it, modes and how to avoid recursion.
• Retry queue (DLQ) — how failed workflows are retried.
• Execute a flow — execution modes, history and traces.