Repository navigation
[BUG]: ready tasks wait for the slowest task in the wave #224
Description
Activity
- added a parent issue
on Jun 11, 2026 Vetted 2026-07-17. The barrier is real on current main: execute() drains each wave's FuturesUnordered fully before recomputing ready_tasks(), so an early finisher waits on its slowest wave sibling (orchestrator.rs:2648-2717). Instrumented runs measured intra-wave skew at 12-26% of wave duration on 3-task waves, but realized waste was zero in every run because no plan had a dependent waiting on a partial wave. gpt-4o-mini never produced a parallel wave at all, though claude coordinators did. One extra finding: ready_tasks() skips tasks with a Failed dependency, meaning a failed task strands its downstream sub-DAG until replan (types.rs:281). The 20-50% figure stays unverified and needs #218's instrumentation on a real workload. Description updated to match.
- changed the title
[-]Wave barrier sequentialization[/-][+][BUG]: ready tasks wait for the slowest task in the wave[/+]on Jul 17, 2026
Wave execution in Orchestrator::execute drains each wave's FuturesUnordered completely before recomputing ready_tasks(), so a task whose dependencies finish early still waits for the slowest task in the current wave (orchestrator.rs:2648-2717 as of 2026-07-17). ready_tasks() also skips tasks with a Failed dependency, stranding the downstream sub-DAG until replan (types.rs:281).
What instrumented runs showed: intra-wave skew of 12-26% of wave duration on 3-task waves, but realized barrier waste was zero in every harness run because no plan had a dependent waiting behind a partial wave. Coordinator behavior matters here. gpt-4o-mini produced only serial plans; claude coordinators parallelized.
Open question this ticket tracks: whether real workloads produce waves where the barrier actually costs something. That needs per-wave timing, which is #218. Gated on #218.