Activation Modes and Timeouts v2
The Runtime changes how a Workflow behaves according to why it was started and whether it is using the current design or a published revision.
Interactive design modes
The Console automatically runs Preview invokes of Workflows to project data and infer schemas without invoking actual Nodes. This happens automatically as the Workflow is being designed. Errors encountered in Preview are shown in the designer's Problems tab.
When a Workflow is run manually from the Design canvas, invoked by the AI assistant or via MCP tool, it runs in Debug mode which does not require Workflow chnanges to be saved or for the Workflow to be enabled. A short default timeout (five minutes) is applied. A Debug run can also use Run from here or Run to here.
When a Debug Workflow begins with a managed trigger (HTTP Receive, MCP Receive, or Schedule Step), the runtime simulates those steps running and projects their hardcoded returns into their connected Properties.
When a Workflow begins with an unmanaged trigger (any other trigger), the trigger is actually invoked and execution will block at the trigger Step until it fires. A single iteration will execute and then the Workflow will stop.
Published activation modes
| Start | Activation | Key behavior |
|---|---|---|
| Run Now or another ad-hoc caller | Run Now | Loads the published revision for the selected Environment. |
| HTTP request | HTTP | Uses the Environment hostname and published route contract. |
| MCP tool call | MCP | Uses the published MCP tool contract and caller authorization. |
| Schedule | Schedule | Starts from the schedule manager at the configured occurrence. |
| Listener | Listener | Keeps a listener activation available to yield external events. |
| Sub-Workflow call | Run Now | Resolves the child published revision in the parent's Site and Environment. |
Published starts require an enabled Workflow. The trigger or caller can add its own request, transport, or operation limits.
Execution timeout and caller wait
An execution timeout sets the maximum lifetime of the Runtime activation. When it expires, Flowgear requests cooperative cancellation of the Workflow and passes that cancellation token to Node Methods that accept it.
A caller wait timeout is different. It limits how long the caller waits for a synchronous result; when the wait expires, the Workflow can continue in the background. Do not assume a client timeout stopped the Workflow. Use the returned instance identity and Workflow Logs to determine its state.
An explicit execution timeout overrides the interactive defaults.
Stop and cleanup
Stop requests cancellation for the current instance. The Runtime checks cancellation between execution frames and supplies it to compatible Node Methods. A long-running Node operation that does not observe cancellation may take time to stop.
The Runtime also releases enumerators, Streams, replay files, and other deferred resources when execution completes or is cancelled. Sub-Workflows share the root cancellation context. A remote child receives the remaining explicit parent deadline rather than starting a new full timeout.
See also
See Triggers, Workflow Status, Compiled execution, and Lazy Evaluation and Streaming.