Two e2e tests now fail every run locally: the storefront renders 1,662 items unpaginated #186

New Issue

2026-08-25T13:21:01-05:00

bermudalamb commented

2026-08-25 13:21:01 -05:00

This has been degrading for a while and has crossed a line today. It is no longer flaky — it fails every time.

✕ filters.spec.ts        › removing a chip widens the results again
✕ favorites-filter.spec.ts › shows a removable chip that restores the full catalogue

Both were reproduced on main with no working-tree changes, serially, at --workers=1. Not a race and not caused by any current branch.

Cause

Both assert that a specific seeded card is visible in the unfiltered grid, immediately after removing a filter. GET /api/items with no filter currently returns 1,662 items, and the storefront renders all of them — there is no pagination and no limit. Rendering that many cards takes longer than the 5 second toBeVisible default.

Every filtered assertion in the same specs passes. The failures track the unfiltered grid exactly, which is what points at volume rather than logic.

Why it got worse

Nothing truncates the development database. Every e2e run seeds more fixtures and leaves them, so the unfiltered grid grows monotonically. It was intermittent at ~1,100 items earlier this week and is now reliable at 1,662. It will keep getting worse, and it does not reproduce in CI, where the database is fresh.

That combination is the worst kind: a suite that fails locally, passes in CI, and gets slowly worse until nobody trusts it.

Two fixes, and they are not the same decision

Paginate the storefront. This is a product change and probably the right one on its own merits — a shop that renders its entire catalogue in one page is not a shop anyone wants at scale, and the grid already has the filter controls that make paging tolerable. It also fixes the tests as a side effect rather than by targeting them.

Reset the development database. A harness change: give the e2e suite a truncation step, or a disposable database like the integration suite already has. Cheaper, does nothing for real users, and is arguably the more honest fix for a test problem — the tests are slow because the fixture data is unbounded, which is a fixture problem.

They are not exclusive and they answer different questions. The first is worth doing regardless; the second is what makes the suite trustworthy tomorrow rather than after a product change.

Not recommended

Raising the timeout on the two failing assertions. That hides a real symptom, and the number would have to keep rising.

Worth noting about the assertions themselves

Both tests assert a specific item is visible in a grid holding every item ever seeded. Even paginated, "this fixture is on page one of an unfiltered catalogue" is not a thing a test can rely on. Whichever fix is chosen, these two assertions are worth rewriting to check what they actually mean — that removing the filter widened the result set — rather than naming an item and hoping it is near the front.

This has been degrading for a while and has crossed a line today. It is no longer flaky — it fails every time. ``` ✕ filters.spec.ts › removing a chip widens the results again ✕ favorites-filter.spec.ts › shows a removable chip that restores the full catalogue ``` Both were reproduced on `main` with no working-tree changes, serially, at `--workers=1`. Not a race and not caused by any current branch. ## Cause Both assert that a specific seeded card is visible in the **unfiltered** grid, immediately after removing a filter. `GET /api/items` with no filter currently returns **1,662 items**, and the storefront renders all of them — there is no pagination and no limit. Rendering that many cards takes longer than the 5 second `toBeVisible` default. Every filtered assertion in the same specs passes. The failures track the unfiltered grid exactly, which is what points at volume rather than logic. ## Why it got worse Nothing truncates the development database. Every e2e run seeds more fixtures and leaves them, so the unfiltered grid grows monotonically. It was intermittent at ~1,100 items earlier this week and is now reliable at 1,662. It will keep getting worse, and it does not reproduce in CI, where the database is fresh. That combination is the worst kind: a suite that fails locally, passes in CI, and gets slowly worse until nobody trusts it. ## Two fixes, and they are not the same decision **Paginate the storefront.** This is a product change and probably the right one on its own merits — a shop that renders its entire catalogue in one page is not a shop anyone wants at scale, and the grid already has the filter controls that make paging tolerable. It also fixes the tests as a side effect rather than by targeting them. **Reset the development database.** A harness change: give the e2e suite a truncation step, or a disposable database like the integration suite already has. Cheaper, does nothing for real users, and is arguably the more honest fix for a *test* problem — the tests are slow because the fixture data is unbounded, which is a fixture problem. They are not exclusive and they answer different questions. The first is worth doing regardless; the second is what makes the suite trustworthy tomorrow rather than after a product change. ## Not recommended Raising the timeout on the two failing assertions. That hides a real symptom, and the number would have to keep rising. ## Worth noting about the assertions themselves Both tests assert a specific item is visible in a grid holding every item ever seeded. Even paginated, "this fixture is on page one of an unfiltered catalogue" is not a thing a test can rely on. Whichever fix is chosen, these two assertions are worth rewriting to check what they actually mean — that removing the filter widened the result set — rather than naming an item and hoping it is near the front.

bermudalamb referenced this issue from a commit

2026-08-25 14:37:22 -05:00

docs(design): filter dimensions, one composable component both screens extend (#188)

bermudalamb referenced this issue from a commit

2026-08-25 14:46:13 -05:00

docs(plan): implementation plan for filter dimensions (#188)

bermudalamb added this to the Code Quality and Hardening 2 project 2026-08-25 16:26:36 -05:00

bermudalamb self-assigned this 2026-08-25 16:26:46 -05:00

bermudalamb referenced this issue

2026-09-02 10:57:21 -05:00

feat(storefront): paginate the catalogue instead of rendering all of it #269

bermudalamb referenced this issue from a commit