Dashboard: merge agent telemetry missing for some waves (snapshot not captured)

[HenryLach]

Problem

After the #498 fix (waveIndex-based merge telemetry matching), some waves show merge telemetry and others show ——. The fix correctly associates telemetry with the right wave, but some waves never get a telemetry snapshot captured.

Evidence

Polyrepo test batch with 5 waves:

• Wave 1: no telemetry (3 repos)
• Wave 2: telemetry shown (11m 29s, 10 tools)
• Wave 3: no telemetry (2 repos)
• Wave 4: telemetry shown (4m 55s, 11 tools)

Likely Cause

The merge snapshot (merge-N.json) is written during merge execution and cleaned up after. Fast merges may complete before the dashboard's next poll captures the snapshot. Or the snapshot is written with a waveIndex that doesn't match the dashboard's expectation.

Fix

Either:

1. Persist merge telemetry in the merge result JSON (already written and retained) so it's always available
2. Or ensure merge snapshots are retained until the dashboard has read them

Related

• Dashboard: merge agent telemetry duplicated across all waves during active merge #498 (original fix for duplicated telemetry)

[HenryLach]

Additional evidence: during Wave 5 merge, Wave 1 showed Wave 5's active merge telemetry via the Priority 2 session-name fallback. Since all waves reuse the same merge session names (orch-henry-merge-1), the session-based fallback can't distinguish between waves.

The Priority 2 fallback should be removed entirely — only the waveIndex-based match (Priority 1) should be used. If no snapshot exists for a wave, show no telemetry rather than wrong telemetry.

[HenryLach]

New evidence — bug is worse than the original framing suggested

Hit this again on a polyrepo test run today (taskplane@0.28.8 + the unmerged PR #556 fixes for #559/#560). The original issue body framed this as "some waves never get a telemetry snapshot captured." The screenshot below shows that's not quite right — the snapshot exists, but it's landing on the wrong wave row.

Repro context

6-wave polyrepo batch across 3 repos (api-service, shared-libs, web-client). All 6 waves merged successfully. Dashboard "Merge Agents" panel after the batch completed:

Wave	Lane(s) merged	Wave-row telemetry shown?	If yes — path written
1	api-service L1, shared-libs L2, web-client L3	—	(none)
2	shared-libs L1, L2	✅ 14m 50s, 6 tools, $0.089	merge-result-w1-lane3-henrylach-20260509T224027.json
3	api-service L1, web-client L2	—	(none)
4	shared-libs L1	✅ 10m 09s, 6 tools, $0.054	merge-result-w3-lane2-henrylach-20260509T224027.json
5	api-service L1	—	(none)
6	web-client L1	—	(none)

The pattern (off-by-one across waves)

The two telemetry rows that ARE displayed reference merge-result paths that belong to a different wave than the row they're attached to:

• Wave 2's row shows telemetry whose path mentions w1-lane3 → that's Wave 1's web-client merge result.
• Wave 4's row shows telemetry whose path mentions w3-lane2 → that's Wave 3's web-client merge result.

In both cases: the wave-N+1 row is attributed the last merge result from wave N. Both wrong-attributed rows happen to trace to a web-client merge from the previous wave specifically — possibly because that was the last lane to finish merging in each preceding wave.

Refined hypothesis

The original issue body suggested:

Fast merges may complete before the dashboard's next poll captures the snapshot. Or the snapshot is written with a waveIndex that doesn't match the dashboard's expectation.

Today's evidence supports the second branch and refines it: the merge-telemetry → wave-row association in the dashboard appears to retain the last-known snapshot from the previous wave and re-render it on the next wave's row when the next wave hasn't (yet, or ever) produced its own snapshot. So waves that genuinely produce a snapshot show it correctly; waves that don't either show "—" (correct) or, depending on render order, show the carryover from the previous wave (incorrect — what we see here).

If that hypothesis is right, the fix is one or both of:

1. The wave-row render should ignore (or display "—" for) merge snapshots whose waveIndex doesn't equal the row's wave index — even if a snapshot is in memory from the previous wave.
2. The merge-snapshot store should clear or stamp expired entries when a new wave begins so stale snapshots can't leak into the new wave's render.

Files (per the original issue body)

• dashboard/public/app.js — merge telemetry rendering per wave (most likely the off-by-one match site)
• dashboard/server.cjs — merge snapshot API response (less likely, but worth checking the ordering of snapshots returned)

Severity

Same as the original — cosmetic but misleading. Operators reading the dashboard see merge telemetry against a wave that didn't produce it, which makes diagnosing real merge issues harder. Mostly noticed after the batch completes (because the wrong-wave row stays displayed).

[HenryLach]

Third reproduction (2026-05-11). Same off-by-one wave attribution pattern observed again on a fresh polyrepo run at the post-batch all-waves-complete state.

This run was on the TP-197 branch (PR #577 + folds) so the dashboard renders are otherwise current; this confirms the off-by-one bug is independent of the recent dashboard changes.

Observed final state

6-wave polyrepo batch across 3 repos (api-service, shared-libs, web-client). All 6 waves merged successfully. Merge Agents panel:

Wave	Lane(s) merged	Telemetry shown?	If yes — path written
1	api-service L1, shared-libs L2, web-client L3	—	(none)
2	shared-libs L1, L2	✅ 12m 32s, 6 tools, $0.087	merge-result-w1-lane3-henrylach-20260511T174523.json
3	api-service L1, web-client L2	—	(none)
4	shared-libs L1	✅ 8m 27s, 5 tools, $0.050	merge-result-w3-lane2-henrylach-20260511T174523.json
5	api-service L1	—	(none)
6	web-client L1	—	(none)

Pattern: same as the 2026-05-07 reproduction — the wave-N+1 row is attributed the last merge result from wave N. Both wrong-attributed rows trace to web-client merges from the preceding wave (the last lane to finish merging in W1 → leaks onto W2; same for W3 → W4).

Diagnostic angle this run adds

This is the third confirmed reproduction with the same exact pattern. The bug is deterministic, not flaky. The previous comment hypothesized "the dashboard's merge-snapshot store retains the last-known snapshot from the previous wave and re-renders it on the next wave's row when the next wave hasn't produced its own snapshot." Today's reproduction is consistent with that hypothesis.

The dashboard's match priority chain (per app.js line ~1232):

1. Priority 1: match by tel.waveIndex === mr.waveIndex from telemetry entries (_source === "merge-snapshot")
2. Priority 2: match by lane-number session
3. Priority 3: effective session telemetry

The fact that the wrong telemetry consistently lands on the row above the snapshot's actual wave suggests Priority 1 is finding an entry whose waveIndex is misindexed — possibly the merge snapshot is being persisted with waveIndex = N+1 when it actually came from wave N, OR the dashboard is reading a stale telemetry record from the previous merge's snapshot that wasn't cleared.

Suggested investigation focus

The next debugging pass should:

1. Inspect currentData.telemetry directly during a multi-wave run and confirm what waveIndex each merge snapshot carries
2. Check whether merge-snapshot files in .pi/runtime/<batchId>/ have correct waveIndex metadata
3. Check whether the dashboard is appending vs replacing telemetry entries across waves (could be growing the telemetry map without clearing old entries)

Will continue to leave open. Not blocking any current release work — purely cosmetic in the post-batch view.