test(e2e): admin-save-failures happy-path test is skipped and needs restoring #245

Closed
opened 2026-08-30 16:18:20 -05:00 by bermudalamb · 1 comment
Owner

admin-save-failures.spec.ts → "saves an item successfully when the server accepts it" is skipped as of 2026-08-30, to get main green while #241 is outstanding.

This is a temporary measure and the coverage it removes is not trivial. The test asserts that adding an item through the admin actually reaches the database — not merely that a toast appeared. It is the happy path for the core admin action, and nothing else covers it end to end.

Why it was skipped rather than fixed

It fails in CI and passes locally. A local parallel run of the whole suite on the same commit failed four different specs — admin-inventory-filters, auth, favorites-filter, resend-verification — and not this one. Which test fails depends on scheduling, which is #241: fullyParallel: true against a single shared database.

Fixing this test individually would be guessing at a symptom. The cause is the isolation, and it moves around.

Ruled out

The re-encoding added in #226 is not involved. AdminInventory.addItem fills a name and a price and clicks save — no image is attached — so stripUploadedImages iterates an empty array and returns immediately. This path does no image work at all.

What restoring it depends on

#241. Once specs cannot see each other's rows, this test should be un-skipped and should pass without modification. If it still fails at that point, it is a real defect and worth chasing on its own.

Do not

Leave this skipped and forget it. A skipped test on the core admin save path is worse than a red build, because a red build is at least visible.

`admin-save-failures.spec.ts` → "saves an item successfully when the server accepts it" is skipped as of 2026-08-30, to get `main` green while #241 is outstanding. **This is a temporary measure and the coverage it removes is not trivial.** The test asserts that adding an item through the admin actually reaches the database — not merely that a toast appeared. It is the happy path for the core admin action, and nothing else covers it end to end. ## Why it was skipped rather than fixed It fails in CI and passes locally. A local parallel run of the whole suite on the same commit failed four *different* specs — `admin-inventory-filters`, `auth`, `favorites-filter`, `resend-verification` — and not this one. Which test fails depends on scheduling, which is #241: `fullyParallel: true` against a single shared database. Fixing this test individually would be guessing at a symptom. The cause is the isolation, and it moves around. ## Ruled out The re-encoding added in #226 is not involved. `AdminInventory.addItem` fills a name and a price and clicks save — no image is attached — so `stripUploadedImages` iterates an empty array and returns immediately. This path does no image work at all. ## What restoring it depends on #241. Once specs cannot see each other's rows, this test should be un-skipped and should pass without modification. If it still fails at that point, it is a real defect and worth chasing on its own. ## Do not Leave this skipped and forget it. A skipped test on the core admin save path is worse than a red build, because a red build is at least visible.
Author
Owner

Restored. The test.skip is gone and the admin-save happy path runs again — it is the only end-to-end check that adding an item reaches the database rather than merely firing a toast.

It came back as part of the #241 work, and the diagnosis in this issue turned out to be only half right. The suite was interfering with itself through the shared database, which is why workers is now 1. But this particular spec had a second, unrelated cause: AdminInventory.confirmButton matched getByRole('button', { name: 'OK' }), and Playwright matches an accessible name as a case-insensitive substring unless exact is passed. A leftover toast reading "Freed rmtiq9okg22k9e" matched it, because the random base36 suffix happened to contain "ok". That reproduced serially, on a fresh database, so no amount of worker reduction would have fixed it — see #253, where it is fixed with exact: true.

Both causes are addressed, and the test has since passed two consecutive full runs plus every run since.

Closes #245

Restored. The `test.skip` is gone and the admin-save happy path runs again — it is the only end-to-end check that adding an item reaches the database rather than merely firing a toast. It came back as part of the #241 work, and the diagnosis in this issue turned out to be only half right. The suite *was* interfering with itself through the shared database, which is why `workers` is now 1. But this particular spec had a second, unrelated cause: `AdminInventory.confirmButton` matched `getByRole('button', { name: 'OK' })`, and Playwright matches an accessible name as a case-insensitive **substring** unless `exact` is passed. A leftover toast reading "Freed rmtiq9okg22k9e" matched it, because the random base36 suffix happened to contain "ok". That reproduced serially, on a fresh database, so no amount of worker reduction would have fixed it — see #253, where it is fixed with `exact: true`. Both causes are addressed, and the test has since passed two consecutive full runs plus every run since. Closes #245
Sign in to join this conversation.
No labels
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: bermudalamb/redefined-designs#245