TASK DAG · CRITICAL BRANCH
Task-DAG scheduling: measure the parallel critical branch
A daily report DAG has three parallel branches; choose which task to speed up and how many worker slots run, and see which branch decides the finish time.
Your experiment
extract_orders takes 10 minutes; then transform_a (20) feeds load_a (5), transform_b (35) feeds load_b (5), and quality_check takes 8; report (5) needs all three branches and is due at 50 minutes. Start by halving transform_a with three worker slots, then speed up other tasks, remove slots and add a 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 scheduler: ready tasks start in declared order whenever a slot is free. Slack comes from the critical-path method on the dependency graph alone; with too few slots the finish time can exceed the critical path. Task names echo a typical Airflow DAG, but no scheduler runs.
Speeding up the wrong task
The daily report DAG starts with extract_orders (10 minutes); then transform_a (20) feeds load_a (5), transform_b (35) feeds load_b (5), and quality_check runs 8 minutes; report (5) needs all three and is due at 50 minutes. The longest path is extract_orders, transform_b, load_b and report: 55 minutes. In the opening run transform_a is made 50% faster. It had 15 minutes of slack and now has 25, but the report still finishes at 55: LATE. Optimising off the critical path changes nothing.
Shorten the critical branch
Set Task to speed up to transform_b. With Speed-up at 50% the branch takes 17.5 minutes, and the transform_a branch becomes critical: the report finishes at 40. 20% is enough, 48 minutes and ON TIME, while 10% gives 51.5 and is still late. quality_check has 32 minutes of slack, so speeding it up does nothing; halving extract_orders, which is on every path, finishes exactly at the 50-minute deadline.
Slots can make every task critical
Worker slots limit how many tasks run at once. With 1 slot every task waits in line and the report finishes at 78 minutes, although the dependency graph alone allows 55: 23 minutes are lost waiting. 2, 3 or 4 slots all finish at 55, because after extract_orders no more than three tasks are ever ready. With 1 slot even halving transform_b only reaches 70.5.
Retries land on the critical path
Check transform_b fails once and reruns. Its 35 minutes double and the report finishes at 90. Halving transform_b’s runtime with the retry brings it back to 55. A retry or slowdown on the critical branch moves the finish time minute for minute, so that branch is where monitoring and alerting should look first.
Reading the run and its limits
Play, Next event, Restart, Speed and Inspection time step through every task in start order, its window and slack, and the result across sixty seconds; the table lists dependencies, start, end and slack for every task. Durations are fixed, ready tasks start in declared order, and slack is computed on the dependency graph alone. Real schedulers add pools, priorities, sensors and variable runtimes.