Skip to content

Wave-merge alert counter overflows denominator: '(N/3)' for N up to totalWaves #562

@HenryLach

Description

@HenryLach

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).

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions