fix(e2e): judge only body-carrying script responses in the ABS SSO spec #132

Merged
dank merged 1 commits from fix/e2e-mime-304 into main 2026-11-03 01:42:28 -08:00
Owner

Problem

The live-fleet gate went red on a healthy server. specs/23-audiobookshelf-sso.spec.ts asserted that every .js response from the LAN door carries a JavaScript MIME. It fired on:

Error: /audiobookshelf/_nuxt/c7f3e29.js arrived as
Expected substring: "javascript"
Received string:    ""

The trace (0-trace.network) shows the same script fetched twice:

# Request Response
1 plain GET 200 — Content-Type: application/javascript; charset=UTF-8, ETag: W/"1417-1a16a46b830", Cache-Control: public, max-age=0
2 If-None-Match + If-Modified-Since 304 Not Modified — no Content-Type, by HTTP spec

max-age=0 plus an ETag makes that revalidation deterministic once the OIDC bounce re-navigates the page, so the assertion failed on every run (2 passed, 1 failed, twice in a row) while the SPA was demonstrably fine.

Fix

Record the status with each captured response and judge only the ones that carried a body. The guard is unchanged where it matters: the defect class this spec was written for is a bundle built for / instead of /audiobookshelf, whose symptom is a 200 answered text/html — still caught, because 200s are still asserted. A 304 is a correct answer about a body that was already fetched, so it cannot be evidence of anything.

The scripts.length > 2 floor now runs against the same filtered set, so the assertion cannot go vacuous: if every script were aborted or revalidated, the floor fails loudly instead of the MIME loop silently passing.

Verification

npx playwright test specs/23-audiobookshelf-sso.spec.ts against the live fleet — 3 passed (setup, the SSO round trip, the level check). This clears the DEPLOY INCOMPLETE state left by the --service pihole --service caddy deploy of 2026-11-03, whose other 38 tests passed.

Full-suite gate re-run after merge: tests/e2e/run.sh.


cwd: /home/blank/.omp/wt/wt-20261030-163847-6d1fc1f · session: 01a18f2e-18b1-7573-bcd5-ac99369f8bcc (build worktree: /tmp/wt-e2e304)

## Problem The live-fleet gate went red on a healthy server. `specs/23-audiobookshelf-sso.spec.ts` asserted that **every** `.js` response from the LAN door carries a JavaScript MIME. It fired on: ``` Error: /audiobookshelf/_nuxt/c7f3e29.js arrived as Expected substring: "javascript" Received string: "" ``` The trace (`0-trace.network`) shows the same script fetched twice: | # | Request | Response | |---|---|---| | 1 | plain GET | `200` — `Content-Type: application/javascript; charset=UTF-8`, `ETag: W/"1417-1a16a46b830"`, `Cache-Control: public, max-age=0` | | 2 | `If-None-Match` + `If-Modified-Since` | `304 Not Modified` — **no `Content-Type`, by HTTP spec** | `max-age=0` plus an `ETag` makes that revalidation deterministic once the OIDC bounce re-navigates the page, so the assertion failed on every run (`2 passed, 1 failed`, twice in a row) while the SPA was demonstrably fine. ## Fix Record the status with each captured response and judge only the ones that carried a body. The guard is unchanged where it matters: the defect class this spec was written for is a bundle built for `/` instead of `/audiobookshelf`, whose symptom is a **200 answered `text/html`** — still caught, because 200s are still asserted. A `304` is a correct answer about a body that was already fetched, so it cannot be evidence of anything. The `scripts.length > 2` floor now runs against the same filtered set, so the assertion cannot go vacuous: if every script were aborted or revalidated, the floor fails loudly instead of the MIME loop silently passing. ## Verification `npx playwright test specs/23-audiobookshelf-sso.spec.ts` against the live fleet — `3 passed` (setup, the SSO round trip, the level check). This clears the `DEPLOY INCOMPLETE` state left by the `--service pihole --service caddy` deploy of 2026-11-03, whose other 38 tests passed. Full-suite gate re-run after merge: `tests/e2e/run.sh`. --- cwd: /home/blank/.omp/wt/wt-20261030-163847-6d1fc1f · session: 01a18f2e-18b1-7573-bcd5-ac99369f8bcc (build worktree: /tmp/wt-e2e304)
dank added 1 commit 2026-11-03 01:39:39 -08:00
A 304 carries no Content-Type by spec, and the OIDC bounce revalidates the entry script (Cache-Control: max-age=0 + ETag), so the blanket MIME assertion failed on a healthy bundle. The HTML-stub class is still caught: 200s are still judged, and the count floor now runs on the same filtered set.
dank merged commit 6083903ccb into main 2026-11-03 01:42:28 -08:00
Sign in to join this conversation.
No Reviewers
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: dank/serverAppConfigs#132