test/unit/queue-trends.test.ts fails intermittently with:
FAIL test/unit/queue-trends.test.ts > does not emit Infinity review velocity when latest totals snapshots share fetchedAt
AssertionError: expected "unavailable" to be "ready"
Observed on #9950 — a PR whose only changed file is .github/workflows/publish-mcp.yml, which cannot affect this code. That is a false positive by construction.
Root cause: a millisecond race in the fixture
atDaysAgo() calls Date.now() per invocation, so timestamps within one test are mutually inconsistent by however long elapsed between the calls:
const sharedAt = atDaysAgo(0); // evaluated at T0
totals(7, { ... }) // calls atDaysAgo(7) at T1 > T0 -> fetchedAt = T1 - 7dbuildWindow anchors on the latest snapshot, not wall-clock:
const targetMs = latestMs - windowDays * day; // = T0 - 7d
const baseline = [...totals].reverse().find(s => Date.parse(s.fetchedAt) <= targetMs);
The "7 days ago" snapshot sits at T1 - 7d, which is newer than T0 - 7d whenever T1 > T0. No baseline is found, every window reports unavailable, and the assertion fails. It passes only when both calls land in the same millisecond — which is almost always, until a machine hiccups between two adjacent lines.
Reproduced deterministically by injecting a 2 ms offset between the two calls: status comes back unavailable, exactly matching CI.
Why this matters more than a flaky test normally would
Reviews are one-shot for everyone but the maintainer. A false red on a contributor PR is not a re-run away from fine — it is an auto-close of correct work, and the contributor cannot reopen. A test that fails on timing alone is therefore a correctness problem for the gate, not just CI noise.
Fix
Anchor every fixture timestamp in the file to a single instant captured once, so all derived times are mutually consistent regardless of execution speed. The production code is correct as written — it is the fixture that is inconsistent with itself.
Worth a broader sweep afterwards for the same Date.now()-per-call pattern in other fixtures.
test/unit/queue-trends.test.tsfails intermittently with:Observed on #9950 — a PR whose only changed file is
.github/workflows/publish-mcp.yml, which cannot affect this code. That is a false positive by construction.Root cause: a millisecond race in the fixture
atDaysAgo()callsDate.now()per invocation, so timestamps within one test are mutually inconsistent by however long elapsed between the calls:buildWindowanchors on the latest snapshot, not wall-clock:The "7 days ago" snapshot sits at
T1 - 7d, which is newer thanT0 - 7dwheneverT1 > T0. No baseline is found, every window reportsunavailable, and the assertion fails. It passes only when both calls land in the same millisecond — which is almost always, until a machine hiccups between two adjacent lines.Reproduced deterministically by injecting a 2 ms offset between the two calls: status comes back
unavailable, exactly matching CI.Why this matters more than a flaky test normally would
Reviews are one-shot for everyone but the maintainer. A false red on a contributor PR is not a re-run away from fine — it is an auto-close of correct work, and the contributor cannot reopen. A test that fails on timing alone is therefore a correctness problem for the gate, not just CI noise.
Fix
Anchor every fixture timestamp in the file to a single instant captured once, so all derived times are mutually consistent regardless of execution speed. The production code is correct as written — it is the fixture that is inconsistent with itself.
Worth a broader sweep afterwards for the same
Date.now()-per-call pattern in other fixtures.