Repository navigation
aggregator: slice3 registry test fails on clean main — no claude-code record via fixture path #3835
Description
Bug: aggregator test slice-3 routes > dns + sessions + pages routes serve fails on clean main
Reproduced 2026-11-01 on a pristine worktree of origin/main (927f383), bun install + bun test test/slice3.test.ts: 23 pass / 1 fail.
Failure: test/slice3.test.ts:506 — expect(registry.records.some((r) => r.source === "claude-code")).toBe(true) receives false.
Context: the test boots the server with PM_AGG_SOURCE="fixtures" and an empty tmp registry file, so the records come from the fixture feed. The unit-level registry tests in the same file pass (recordFromSessionEntry still produces source: "claude-code", src/registry.ts:76), so either the fixture data no longer contains a claude-code session record, or the fixture→registry path drops/renames that source. Live /sessions works (694 records), so this looks like fixture drift vs the test's expectation — but the fix should be made at whichever layer actually changed: regenerate/repair the fixture, or restore the source mapping if the server path regressed.
Found during the 2026-11-01 PM-stack page-by-page review (not caused by the quota pool change in PR for openai.alternate — the failure predates it on unmodified main).
Acceptance criteria
bun test test/slice3.test.tspasses in full (24/24) on a pristine worktree of current main, includingslice-3 routes > dns + sessions + pages routes serveasserting aclaude-coderegistry record via the fixture path.- The fix lands at the layer that actually changed — the fixture data is regenerated/repaired if the fixture drifted, or the fixture→registry source mapping is restored if the server path regressed — with the diagnosis stated on this issue.
- The test's expectation is not weakened or deleted to make it pass without a stated justification that the
claude-codesource is intentionally gone from fixtures.
Activity
dezren39 commentedon Nov 2, 2026
Intake review
927f38307). The unit-level registry tests in the same file pass (recordFromSessionEntrystill producessource: "claude-code",src/registry.ts:76), which narrows the break to fixture data or the fixture→registry path.recordFromSessionEntryemits for a claude-code session entry; whichever side dropped the source is the fix site.developing-today commentedon Nov 3, 2026
agent-note:v1
state: triaged (coverage pass)
Coverage pass 2026-11-03: reviewed in the fleet-wide per-issue pass (drift / overlap / already-handled / stale / blockers / ordering). Verdict: still live; queued in repo-health-code-pilot as triage at priority 40 (priority/normal). If this is already handled at current main, the triage closes it with evidence; if it needs splitting, the triage files the split.
Found via: coverage pass 2026-11-03
dezren39 commentedon Nov 3, 2026
🤖 Agent note · picked up
dezren39 commentedon Nov 3, 2026
🤖 Agent note · done
Triage findings — already fixed on main, diagnosis
Reproduction attempt at current main: on a pristine laptop worktree of origin/main (37a684d),
bun install+bun test test/slice3.test.tsin pm-stack/aggregator: 36 pass / 0 fail (211 expect() calls), run twice with the same result. The named testslice-3 routes > dns + sessions + pages routes servepasses, and itsclaude-codeassertion is intact and unweakened (test/slice3.test.ts:771).Root cause (neither fixture drift nor a registry source-mapping regression): the fixture session records carry a fixed last-activity date, and
/api/registry.jsondefaults to a 7-day activity window. As calendar time passed the fixture date, the records aged out of the default window, soregistry.recordscontained noclaude-coderecord — the failure was date-dependent, which is why it appeared on clean main on 2026-11-01.Fix already landed: commit 2296432 ("test(pm-stack): make dated registry + pace fixtures time-independent (#1213)", merged via PR #4011, verified an ancestor of current origin/main) changed the test to request
/api/registry.json?window=allwith an in-code comment stating exactly this diagnosis, and made the dated pace fixtures in src/sources/fixtures.ts relative (daysAgo(-1)) instead of fixed past dates.No follow-up fix task is needed: the acceptance criteria are met on current main (full slice3 file passes; the fix sits at the layer that actually changed — the test's window semantics vs fixed fixture dates; the expectation was not weakened).