Wave-merge progress counter formats (N/3) past 3 — denominator uses task-level wave count, numerator counts segment-level merges
Version: taskplane@0.28.8
Severity: Cosmetic — purely a display issue. Functionality is correct (every wave merged successfully); only the alert text reads strangely.
Symptom
In a clean polyrepo run with 3 task-level waves expanded into 6 segment-level waves (one task, TP-006, fans out across 3 repos and contributes 3 segment waves; two tasks, TP-004 and TP-005, contribute 2 each via their shared-libs → downstream-repo segment chain), the merge alerts emitted across the run were:
✅ Wave 1 merged successfully (1/3). Tests pass.
✅ Wave 2 merged successfully (2/3). Tests pass.
✅ Wave 3 merged successfully (3/3). Tests pass.
✅ Wave 4 merged successfully (4/3). Tests pass. ← denominator should be 6
✅ Wave 5 merged successfully (5/3). Tests pass. ← same
✅ Wave 6 merged successfully (6/3). Tests pass. ← same
The first three reads correctly because numerator and denominator happen to share a value in segment-1-of-1 cases. From wave 4 onward the numerator (segment-level wave merge count) overflows the denominator (task-level wave count, taskLevelWaveCount = 3 per batch-state.json).
Root cause hypothesis
batch-state.json for this batch carries:
{
"currentWaveIndex": ...,
"totalWaves": 6, // segment-level
"taskLevelWaveCount": 3, // task-level
"roundToTaskWave": [0, 1, 1, 2, 2, 2],
"wavePlan": [
["TP-001","TP-002","TP-003"],
["TP-004","TP-005"],
["TP-004","TP-005"],
["TP-006"],
["TP-006"],
["TP-006"]
]
}
So both quantities are tracked correctly. The (N/M) rendering in the merge alert appears to be pulling its numerator from the segment-level merge counter (matches currentWaveIndex + 1, range 1-6) but its denominator from taskLevelWaveCount (3) instead of totalWaves (6). Since totalWaves is the right value to compare an incrementing currentWaveIndex + 1 against, the denominator is the bug.
Suggested fix
In whatever formatter emits the Wave N merged successfully (X/Y) alert, change the Y source from taskLevelWaveCount to totalWaves. Both fields are already on batch-state.json; this is a one-character source-of-truth swap.
Lower-effort alternative: render as (wave M of totalWaves segment-waves) to disambiguate, since the numerator and denominator units are no longer in sync after segments expand.
How I noticed
Polyrepo regression run on this workspace (3 repos, 6 tasks, with TP-006 fanning out across all three repos for a 3-segment final task). Functionally clean run — 6/6 tasks succeeded, all wave merges passed tests, batch closed in 13 min at $0.78. The counter values were the only thing off.
Suggested regression test
Use a minimal polyrepo fixture with one fan-out task (1 task → 3 segments → 3 segment-waves). Assert the third merge alert text contains (3/3), not (3/1).
Wave-merge progress counter formats
(N/3)past 3 — denominator uses task-level wave count, numerator counts segment-level mergesVersion: taskplane@0.28.8
Severity: Cosmetic — purely a display issue. Functionality is correct (every wave merged successfully); only the alert text reads strangely.
Symptom
In a clean polyrepo run with 3 task-level waves expanded into 6 segment-level waves (one task, TP-006, fans out across 3 repos and contributes 3 segment waves; two tasks, TP-004 and TP-005, contribute 2 each via their
shared-libs → downstream-reposegment chain), the merge alerts emitted across the run were:The first three reads correctly because numerator and denominator happen to share a value in segment-1-of-1 cases. From wave 4 onward the numerator (segment-level wave merge count) overflows the denominator (task-level wave count,
taskLevelWaveCount = 3perbatch-state.json).Root cause hypothesis
batch-state.jsonfor this batch carries:{ "currentWaveIndex": ..., "totalWaves": 6, // segment-level "taskLevelWaveCount": 3, // task-level "roundToTaskWave": [0, 1, 1, 2, 2, 2], "wavePlan": [ ["TP-001","TP-002","TP-003"], ["TP-004","TP-005"], ["TP-004","TP-005"], ["TP-006"], ["TP-006"], ["TP-006"] ] }So both quantities are tracked correctly. The
(N/M)rendering in the merge alert appears to be pulling its numerator from the segment-level merge counter (matchescurrentWaveIndex + 1, range 1-6) but its denominator fromtaskLevelWaveCount(3) instead oftotalWaves(6). SincetotalWavesis the right value to compare an incrementingcurrentWaveIndex + 1against, the denominator is the bug.Suggested fix
In whatever formatter emits the
Wave N merged successfully (X/Y)alert, change theYsource fromtaskLevelWaveCounttototalWaves. Both fields are already onbatch-state.json; this is a one-character source-of-truth swap.Lower-effort alternative: render as
(wave M of totalWaves segment-waves)to disambiguate, since the numerator and denominator units are no longer in sync after segments expand.How I noticed
Polyrepo regression run on this workspace (3 repos, 6 tasks, with TP-006 fanning out across all three repos for a 3-segment final task). Functionally clean run — 6/6 tasks succeeded, all wave merges passed tests, batch closed in 13 min at $0.78. The counter values were the only thing off.
Suggested regression test
Use a minimal polyrepo fixture with one fan-out task (1 task → 3 segments → 3 segment-waves). Assert the third merge alert text contains
(3/3), not(3/1).