Flaky: the virtualizer window test times out at 5s under CI load #147

New issue

Closed

opened 2026-08-06 17:48:57 +00:00 by claude-bot · 0 comments

claude-bot commented

2026-08-06 17:48:57 +00:00

Severity: LOW, but it costs a CI run each time

frontend/src/pages/PhotoBrowserPage.test.tsx:460 — "keeps the rendered tiles far fewer than the six hundred photos on the page" — failed on CI run 73:

Error: Test timed out in 5000ms.
  ❯ src/pages/PhotoBrowserPage.test.tsx:460:3
Tests  1 failed | 249 passed (250)
Duration 88.93s (… tests 121.07s, environment 95.33s …)

The same commit passed on run 74, and the whole suite passes locally, so this is timing rather than a defect in the code under test.

The tests 121.07s against a 88.93s wall clock is the tell: the runner was heavily contended, and this particular test builds a six-hundred-photo fixture and waits on the virtualizer to settle. Five seconds is comfortable on a developer machine and is not always comfortable on a shared runner mid-import.

Why it is worth fixing rather than re-running

A flake here is expensive out of proportion to its size. It failed the frontend job, which publish gates on (needs: [backend, frontend, e2e]) — so on a tag push, this test alone can stop an image being built, and the failure has nothing to do with what changed.

It also erodes the thing the suite is for. This repository has found three tests this month that passed while covering nothing; a test that fails while nothing is wrong is the same problem from the other side, and the usual response — re-run it — is exactly the habit that lets a real failure through.

Options, in the order I would try them

Give this test its own timeout. it("…", { timeout: 20_000 }) — the fixture is genuinely large and the assertion is about how many tiles render, not how fast. Smallest change, no loss of coverage.
Shrink the fixture. Six hundred photographs proves windowing; so does a hundred, at a sixth of the setup cost. Worth checking the assertion still distinguishes a windowed grid from a fully rendered one at the smaller size — if it does not, the number is load-bearing and option 1 is the answer.
Raise testTimeout globally. Least targeted, and it slows the feedback on every genuinely hung test. Last resort.

Whatever is chosen, the fix should be verified by running the frontend suite under artificial load rather than on an idle machine, or it will look fixed and not be.

References

frontend/src/pages/PhotoBrowserPage.test.tsx:460
CI run 73 (cbae4b1), frontend job — passed on run 74 for the same commit
.forgejo/workflows/ci.yml — publish gates on frontend

## Severity: LOW, but it costs a CI run each time `frontend/src/pages/PhotoBrowserPage.test.tsx:460` — *"keeps the rendered tiles far fewer than the six hundred photos on the page"* — failed on CI run 73: ``` Error: Test timed out in 5000ms. ❯ src/pages/PhotoBrowserPage.test.tsx:460:3 Tests 1 failed | 249 passed (250) Duration 88.93s (… tests 121.07s, environment 95.33s …) ``` **The same commit passed on run 74**, and the whole suite passes locally, so this is timing rather than a defect in the code under test. The `tests 121.07s` against a 88.93s wall clock is the tell: the runner was heavily contended, and this particular test builds a six-hundred-photo fixture and waits on the virtualizer to settle. Five seconds is comfortable on a developer machine and is not always comfortable on a shared runner mid-import. ## Why it is worth fixing rather than re-running A flake here is expensive out of proportion to its size. It failed the **frontend** job, which `publish` gates on (`needs: [backend, frontend, e2e]`) — so on a tag push, this test alone can stop an image being built, and the failure has nothing to do with what changed. It also erodes the thing the suite is for. This repository has found three tests this month that passed while covering nothing; a test that fails while nothing is wrong is the same problem from the other side, and the usual response — re-run it — is exactly the habit that lets a real failure through. ## Options, in the order I would try them 1. **Give this test its own timeout.** `it("…", { timeout: 20_000 })` — the fixture is genuinely large and the assertion is about how many tiles render, not how fast. Smallest change, no loss of coverage. 2. **Shrink the fixture.** Six hundred photographs proves windowing; so does a hundred, at a sixth of the setup cost. Worth checking the assertion still distinguishes a windowed grid from a fully rendered one at the smaller size — if it does not, the number is load-bearing and option 1 is the answer. 3. **Raise `testTimeout` globally.** Least targeted, and it slows the feedback on every genuinely hung test. Last resort. Whatever is chosen, the fix should be verified by running the frontend suite under artificial load rather than on an idle machine, or it will look fixed and not be. ## References - `frontend/src/pages/PhotoBrowserPage.test.tsx:460` - CI run 73 (`cbae4b1`), frontend job — passed on run 74 for the same commit - `.forgejo/workflows/ci.yml` — `publish` gates on `frontend`