WORKFLOW RUNTIME · TASK STATES
Workflow runtime: inspect ready, running and blocked states
Schedule six dependent tasks on a small worker pool, fail an API task, and watch ready, running, failed, blocked and cancelled states.
Your experiment
A extracts data; B cleans it and C enriches it through an API; D aggregates B’s output and E embeds C’s; F publishes once D and E are done. Start with C failing once, no retries and no blocked propagation, then add propagation, retries, workers and fail-fast.
Play replays the computed run over sixty inspection seconds; Next event steps, Restart rewinds, Speed changes the pace and Inspection time scrubs. Any input change recomputes the run and rewinds it without autoplay.
Event trace
Computed data
Final metrics
Deterministic list scheduler: ready tasks start in alphabetical order whenever a worker is free; durations are fixed (A 4 s, B 3 s, C 5 s, D 3 s, E 4 s, F 2 s); a failed attempt takes the full duration. No workflow engine runs; the states are the ones most engines expose under different names.
A run that never ends
Six tasks form a small graph: A extracts, B cleans and C enriches through an external API, D aggregates B’s output, E embeds C’s, and F publishes when D and E are done. With 2 workers, A runs from 0 to 4 s, then B and C start together; B finishes at 7 s and D runs from 7 to 10 s. C’s API fails its only attempt at 9 s. In the opening run the runtime does not mark dependants, so E and F stay PENDING after the last worker goes idle at 10 s: STALLED, with 3 of 6 tasks done. A dashboard shows this run as still in progress forever.
Make blocked a real state
Check Mark dependants of a failed task BLOCKED. At 9 s E is blocked because C will never succeed, and F because E will not: the run ends at 10 s as FAILED, STATES CONSISTENT, with every task terminal. After a task fails for good applies once blocked states are propagated: Cancel running tasks (fail fast) cancels D at 9 s, so the run ends a second earlier with 2 of 6 done. Letting independent branches finish keeps D’s output for a later rerun.
Retries change the failure into a delay
External API used by task C fails only its first attempt. Set Retries allowed for C to 1: C becomes READY again at 9 s, succeeds at 14 s, E runs from 14 to 18 s and F publishes at 20 s: COMPLETED. With Fails on every attempt, 2 retries only postpone the failure to 19 s. A retry budget is for transient faults; it cannot fix a permanent one.
Workers and the critical path
With Always succeeds, 2 workers finish at 15 s and 1 worker needs 21 s, because every task waits in line. 3 workers still finish at 15 s: after A, at most two tasks are ever ready at once, and the path A, C, E, F takes 4 + 5 + 4 + 2 = 15 s regardless of workers. More workers help only where the ready set is wider than the pool.
Reading the run and its limits
Play, Next event, Restart, Speed and Inspection time step through every state change, with its simulated time, across sixty inspection seconds; each task lane shows its transitions and the table lists attempts, start, end and final state. The scheduler is deterministic and starts ready tasks alphabetically; durations are fixed and a failed attempt takes its full duration. Real engines add timeouts, heartbeats, pools, priorities and partial reruns.