The Workflow Engine · 05.02
Inside a Tick: What Actually Happens When a Run Executes
The exact loop: draining the ready queue up to a parallelism cap, a three-way dispatch decision per node, and the counter that stops a run from settling mid-dispatch.
One tick, drained to a parallelism cap
A tick does one thing repeatedly: while the ready queue has work and the number of currently active executions is under the configured parallelism cap, it pulls the next queued item and looks up its node. For that node, dispatch readiness resolves to exactly one of three outcomes — the node is genuinely ready to dispatch, it's waiting (its required input hasn't arrived yet, so it's parked in a waiting-inputs buffer instead of dispatched), or it's skipped (unreachable given how the graph actually branched, marked so explicitly rather than left to silently never fire). Only the first outcome results in real dispatch; the other two are handled inline in the same loop, not as separate passes.
A run can't settle out from under a passthrough node
Deciding a run is actually finished requires three things to be true simultaneously: the ready queue is empty, there are zero active executions, and a separate in-flight-dispatch counter is also at zero. That third counter exists for a specific, easy-to-miss correctness trap: passthrough node kinds like trigger, merge, router, and scratchpad never register themselves in the active-executions map at all — they're synchronous and instant. Without the separate counter, a run could appear to have zero active executions and an empty ready queue for a brief moment while a passthrough node was still mid-dispatch, and get incorrectly marked settled. The counter is incremented before dispatch and decremented only after the dispatch chain (success or failure bookkeeping) is durable, so a fast passthrough node can never race the settlement check.
Underneath the tick: the durable spine, not a special case
None of this tick machinery is a bespoke persistence layer bolted onto the engine — a run's state is itself durable exactly the way a Durable Entity is durable, and every state transition is recorded to the ledger and published on the EventBus the same way any other cross-cutting event in the platform is. The Workflow Engine is a specific, sophisticated consumer of the general durable spine — not a parallel system that happens to also survive a restart.
Continue
Most automation reports success the moment every step fires. The Workflow Engine refuses that shortcut — it checks the world, heals what it can, and names honestly what it can't.
The five-stage discipline behind every hardened workflow, from declaring how success will be verified to a verdict engine that never trusts a self-report.