rbrooks/Quest-Board

Watch

Fork 0

Home's clear-out countdown was asserting on the clock (#727) #755

Merged

claude-bot merged 1 commit from fix/home-countdown-flake into main

2026-09-22 17:30:34 +00:00

claude-bot commented

2026-09-22 16:55:09 +00:00

Collaborator

A one-line test fix, with its reasoning, because it turned a green tree red on an unrelated PR and would have kept doing it.

What happened

Home.test.jsx's bin fixture set purge_at to exactly Date.now() + 5 days + 3 hours, evaluated once, when the module loads. The page then reads the clock floored to the minute (useMinute, Home.jsx:80) and gap() floors again to whole hours.

So "gone for good in 5 days, 3 hours" was true only while the render happened in the same minute the fixture was built. The moment the suite crossed a minute boundary on its way to that test — which depends on nothing but where in the minute the run started and how long the preceding thirty tests took — the remaining gap became 5d 2h 59m and the text became "5 days, 2 hours".

It did exactly that on #754, a backend-only PR, while the identical frontend code was green on main in run 10208. That is what a flaky test looks like from the outside: a red job on a change that cannot have caused it, and a re-run that probably goes green.

The fix

A 30-minute cushion on the fixture, so the floored hour is the same answer for any drift this suite could plausibly have.

Nothing is loosened. The assertion still names the exact words — the point of the test is that the countdown says the right thing, and a test that matched /gone for good/ would stop checking the thing it exists to check.

The sibling fixture at line 96 has an hour of slack and an assertion that reads only the days, so it is not exposed; I looked rather than assuming.

Checks

npx vitest run src/pages/Home.test.jsx in node:24-alpine: 31 passed.

🤖 Generated with Claude Code

A one-line test fix, with its reasoning, because it turned a green tree red on an unrelated PR and would have kept doing it. ## What happened `Home.test.jsx`'s bin fixture set `purge_at` to exactly `Date.now() + 5 days + 3 hours`, evaluated **once, when the module loads**. The page then reads the clock **floored to the minute** (`useMinute`, `Home.jsx:80`) and `gap()` floors again to whole hours. So `"gone for good in 5 days, 3 hours"` was true only while the render happened in the same minute the fixture was built. The moment the suite crossed a minute boundary on its way to that test — which depends on nothing but where in the minute the run started and how long the preceding thirty tests took — the remaining gap became `5d 2h 59m` and the text became **"5 days, 2 hours"**. It did exactly that on **#754**, a *backend-only* PR, while the identical frontend code was green on `main` in run 10208. That is what a flaky test looks like from the outside: a red job on a change that cannot have caused it, and a re-run that probably goes green. ## The fix A 30-minute cushion on the fixture, so the floored hour is the same answer for any drift this suite could plausibly have. **Nothing is loosened.** The assertion still names the exact words — the point of the test is that the countdown says the right thing, and a test that matched `/gone for good/` would stop checking the thing it exists to check. The sibling fixture at line 96 has an hour of slack and an assertion that reads only the days, so it is not exposed; I looked rather than assuming. ## Checks `npx vitest run src/pages/Home.test.jsx` in `node:24-alpine`: **31 passed**. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

claude-bot added 1 commit

2026-09-22 16:55:09 +00:00

test(frontend): Home's clear-out countdown was asserting on the clock (#727 )

CI / Backend lint (ruff) (pull_request) Successful in 56s

Details

CI / Bot/backend version sync (pull_request) Successful in 24s

Details

CI / Summarisation accuracy eval harness (stub provider) (pull_request) Successful in 1m30s

Details

CI / Feedback site tests (pull_request) Successful in 39s

Details

CI / Bot tests and audit (pull_request) Successful in 2m46s

Details

CI / Frontend tests, audit, and build (pull_request) Successful in 3m29s

Details

CI / Docker image build (pull_request) Successful in 4m15s

Details

CI / End-to-end journeys (desktop, phone, keyboard-only) (pull_request) Successful in 3m29s

Details

CI / Backend migration, tests, and audit (pull_request) Successful in 13m57s

Details

CI / Synthetic session harness (no GPU, no LLM) (pull_request) Successful in 18m43s

Details

e852c22808

`BINNED.purge_at` was fixed at module load as exactly `+5 days 3 hours`, and
the page reads the clock floored to the minute (`useMinute`) before `gap()`
floors again to whole hours. So the assertion held only while the render
landed in the same minute the fixture was built: the moment the suite crossed
a minute boundary on its way to that test, the gap became 5d 2h 59m and the
text became "5 days, 2 hours".

It failed that way on #754 — a backend-only PR — while the identical frontend
code was green on main, which is what a flaky test looks like from the outside
and costs a CI cycle every time.

A 30-minute cushion makes the floored hour the same answer for any drift this
suite could plausibly have. Nothing is loosened: the assertion still names the
exact words.

The sibling fixture at line 96 has an hour of slack and an assertion that only
reads the days, so it is not exposed.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

claude-bot merged commit f1fc69a751 into main

2026-09-22 17:30:34 +00:00

claude-bot referenced this pull request from a commit

2026-09-22 17:30:35 +00:00

Merge PR #755: Home's clear-out countdown was asserting on the clock (#727)

claude-bot referenced this pull request

2026-09-22 21:17:32 +00:00

Build lane 2: the public pages (PUB-1 to PUB-12) #728

rbrooks referenced this pull request from a commit

2026-09-23 06:20:59 +00:00

test(frontend): give findBy the headroom the test timeout already has (#729)

claude-bot referenced this pull request