frontend/app/e2e/gallery.spec.ts:398 — test("tiles never overlap, at any density") — failed and
passed on retry on both local bash scripts/check.sh browser runs of 2026-08-10, against two
diffs that could not plausibly have caused it, and has not failed in CI.
Observed
| Run |
Diff under test |
Result |
| local |
the cool-down lockfile fix (#507) — tooling only, no frontend file touched |
1 flaky, 248 passed |
| local |
the request-model tightening (#508) — no frontend layout change |
1 flaky, 248 passed |
| CI (both PRs) |
same commits |
annotator e2e (chromium) green, no retry reported |
Playwright reports it as flaky rather than failed, so the suite exits zero and the run reads green
in the timing summary — the only trace is the line above the totals and a screenshot at
test-results/gallery-tiles-never-overlap-at-any-density-chromium/test-failed-1.png.
Two-for-two on unrelated diffs, on one machine and not on the runners, points at the test rather
than at any change.
Where to look
The test guards a real defect (the row height was estimated from minColumn while the grid packs
to a different column count), so the assertion is worth keeping — the question is what makes it
race.
- A re-flow it does not await. The grid is virtualized over rows and the density control
changes column count; a measurement taken between the density change and the resulting layout
pass would read stale geometry. Worth checking whether the assertion waits for anything the
browser guarantees has settled, or only for the elements to exist.
- A viewport disagreement. Column count is a function of available width. If the local browser
and the runner resolve a different viewport — or if a scrollbar appears on one and not the other
— the density ladder lands on different column counts, and only some of them race.
tests/scripts/e2e_discipline.test.mjs forbids clock waits in this suite, so the repair has to be
a condition the test can assert on rather than a pause.
Why it is worth fixing rather than tolerating
A gate that is sometimes red for no reason is a gate people learn to re-run instead of read, and
this one is guarding a layout invariant that has already regressed once, when the gallery rendered
one tile per row at every width because the ResizeObserver was never attached (#159). A flake
here spends the credibility of every other assertion in the file.
frontend/app/e2e/gallery.spec.ts:398—test("tiles never overlap, at any density")— failed andpassed on retry on both local
bash scripts/check.sh browserruns of 2026-08-10, against twodiffs that could not plausibly have caused it, and has not failed in CI.
Observed
1 flaky, 248 passed1 flaky, 248 passedannotator e2e (chromium)green, no retry reportedPlaywright reports it as flaky rather than failed, so the suite exits zero and the run reads green
in the timing summary — the only trace is the line above the totals and a screenshot at
test-results/gallery-tiles-never-overlap-at-any-density-chromium/test-failed-1.png.Two-for-two on unrelated diffs, on one machine and not on the runners, points at the test rather
than at any change.
Where to look
The test guards a real defect (the row height was estimated from
minColumnwhile the grid packsto a different column count), so the assertion is worth keeping — the question is what makes it
race.
changes column count; a measurement taken between the density change and the resulting layout
pass would read stale geometry. Worth checking whether the assertion waits for anything the
browser guarantees has settled, or only for the elements to exist.
and the runner resolve a different viewport — or if a scrollbar appears on one and not the other
— the density ladder lands on different column counts, and only some of them race.
tests/scripts/e2e_discipline.test.mjsforbids clock waits in this suite, so the repair has to bea condition the test can assert on rather than a pause.
Why it is worth fixing rather than tolerating
A gate that is sometimes red for no reason is a gate people learn to re-run instead of read, and
this one is guarding a layout invariant that has already regressed once, when the gallery rendered
one tile per row at every width because the
ResizeObserverwas never attached (#159). A flakehere spends the credibility of every other assertion in the file.