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.
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.
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
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
admin-save-failures.spec.ts→ "saves an item successfully when the server accepts it" is skipped as of 2026-08-30, to getmaingreen 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: trueagainst 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.addItemfills a name and a price and clicks save — no image is attached — sostripUploadedImagesiterates 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.
Restored. The
test.skipis 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
workersis now 1. But this particular spec had a second, unrelated cause:AdminInventory.confirmButtonmatchedgetByRole('button', { name: 'OK' }), and Playwright matches an accessible name as a case-insensitive substring unlessexactis 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 withexact: true.Both causes are addressed, and the test has since passed two consecutive full runs plus every run since.
Closes #245