EXECUTION PLAN · DEPENDENCIES · ACCEPTANCE
Execution plan: dependencies, deadlines and acceptance
Schedule a six-step plan on a few workers, inject one defective artifact, and see whether checking acceptance early or late meets the deadline.
Your experiment
The plan is fetch, parse, then summarize and chart in parallel, then assemble and verify. Start with acceptance only at the end and a defective parse, then check after every step, change the workers and deadline, skip checks entirely and remove the retry.
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 scheduling in whole seconds, not an ADK planner. A worker takes the ready step whose inputs finished first; a failed check retries the step at once on the same worker; an end-only failure reruns the faulty step and everything that depends on it. Durations are fixed and the injected defect affects only the first attempt.
A plan with a hidden defect
The plan runs fetch for 3 s, parse for 4 s, then summarize for 8 s and chart for 6 s in parallel, then assemble for 3 s and verify for 2 s. Two workers, a 30 s deadline and one retry. The opening Injected defect makes parse produce, on its first attempt, an artifact that fails its row check. With Where acceptance is checked set to Only by the final verify step, everything downstream is built on the bad parse, verify catches the defect at 20 s, and parse, summarize, chart, assemble and verify all run again: the plan finishes at 37 s, DEADLINE MISSED after 11 attempts.
Check acceptance after every step
Choose After every step. Each checked step costs one extra second, but the bad parse is caught at 8 s and redone by 13 s before anything depends on it. The plan finishes at 27 s: ON TIME AND ACCEPTED with 7 attempts. With no defect the per-step checks cost time instead, 22 s against 20 s for end-only checking, which is why the choice depends on how often steps fail.
Workers, deadline and the late defect
With one worker the steps run serially: 49 s with end-only checks and 34 s with per-step checks, both too late for 30 s. A third worker gives nothing over two, because at most two steps are ever ready together. A defective chart is cheaper to find late, since only chart, assemble and verify rerun, but still finishes at 31 s, one second past the deadline; per-step checks finish at 27 s. With a 40 s deadline the default plan is accepted at 37 s.
Skipping checks, and running out of retries
Never (verify skipped) is fastest, 18 s, and ships the defective artifact: DEFECT SHIPPED. Speed without acceptance only delivers the wrong result sooner. Set Retries per failed acceptance to 0 and the first failed check stops the plan: NOT DELIVERED, which is safe but late. A second retry adds nothing here because the defect affects only the first attempt.
Reading the run and its limits
Play, Next event, Restart, Speed and Inspection time step through the plan, each step attempt with its worker and acceptance result, any rerun and the verdict across sixty inspection seconds; the table lists every attempt. The scheduler is a simple list scheduler in whole seconds with fixed durations; a failed check retries immediately on the same worker. Real planners also estimate durations, replan around failures and weigh partial results.