test(e2e): re-fixme auth-ui pending PMS-148 login race #131

Merged

nrupard merged 1 commit from fix/pms-148-refixme-auth-ui into main

2026-06-08 00:26:22 +02:00

nrupard commented

2026-06-08 00:23:10 +02:00

Owner

Summary

PR #130 (PMS-142 v2) un-fixme'd the auth-ui Playwright login + logout round-trip on the basis that the BUNYIP-53 /logout fix had landed on staging. That premise is correct: bunyip-api 98ca4dc on staging contains BUNYIP-53 (467ab5a, PR #67) and the follow-up PR #70, so the original blocker is genuinely gone.

The post-merge CI run exposed a separate, deterministic failure mode unrelated to BUNYIP-53: the auth-ui project's login stalls every time it runs after the setup project finishes. URL trail ends at the hub /login and the request log shows no POST /login for the form submit. The same loginViaSpa helper that setup uses succeeds in the same run, so the issue is auth-ui-specific (project isolation, hydration timing, or rate-limit interaction with setup's prior login attempt).

Tracking the root-cause hunt as PMS-148 with a diagnostic-first plan. This PR just stops the bleeding by re-applying test.fixme so main's CI is not stuck red while that work happens.

Changes

e2e/tests/auth.spec.ts: re-add test.fixme, replace the now-obsolete BUNYIP-53 narrative addition with a short PMS-148 pointer. Test body and logout() defenses unchanged.
e2e/README.md: restore the quarantine notes (What it covers row + auth-ui project paragraph), pointing readers at PMS-148 instead of BUNYIP-53.

Test plan

CI Check green.
Post-merge e2e CI: auth-ui is skipped (fixme), other projects (setup, api) continue to pass as before.

Followups

PMS-148: diagnose and fix the auth-ui login race, then attempt un-fixme #3.

## Summary PR #130 (PMS-142 v2) un-fixme'd the `auth-ui` Playwright login + logout round-trip on the basis that the BUNYIP-53 `/logout` fix had landed on staging. That premise is correct: bunyip-api `98ca4dc` on staging contains BUNYIP-53 (`467ab5a`, PR #67) and the follow-up PR #70, so the original blocker is genuinely gone. The post-merge CI run exposed a separate, deterministic failure mode unrelated to BUNYIP-53: the auth-ui project's login stalls every time it runs after the `setup` project finishes. URL trail ends at the hub `/login` and the request log shows no `POST /login` for the form submit. The same `loginViaSpa` helper that setup uses succeeds in the same run, so the issue is auth-ui-specific (project isolation, hydration timing, or rate-limit interaction with setup's prior login attempt). Tracking the root-cause hunt as PMS-148 with a diagnostic-first plan. This PR just stops the bleeding by re-applying `test.fixme` so main's CI is not stuck red while that work happens. ## Changes - `e2e/tests/auth.spec.ts`: re-add `test.fixme`, replace the now-obsolete BUNYIP-53 narrative addition with a short PMS-148 pointer. Test body and `logout()` defenses unchanged. - `e2e/README.md`: restore the quarantine notes (`What it covers` row + `auth-ui project` paragraph), pointing readers at PMS-148 instead of BUNYIP-53. ## Test plan - [ ] CI `Check` green. - [ ] Post-merge `e2e` CI: `auth-ui` is skipped (fixme), other projects (setup, api) continue to pass as before. ## Followups - PMS-148: diagnose and fix the auth-ui login race, then attempt un-fixme #3.

nrupard added 1 commit

2026-06-08 00:23:10 +02:00

test(e2e): re-fixme auth-ui pending PMS-148 login race

E2E (staging) / Playwright against staging (pull_request) Successful in 23s

Details

Check / fmt + clippy + compile + tests (pull_request) Successful in 58s

Details

Create release / Create release from merged PR (pull_request) Has been skipped

Details

82418fce61

PR #130 (PMS-142 v2) un-fixme'd the auth-ui Playwright login + logout round-trip on the basis that the BUNYIP-53 /logout fix landed on staging. That is true: bunyip-api `98ca4dc` on staging includes BUNYIP-53 (`467ab5a`, PR #67) and the follow-up PR #70, so the original blocker is gone.

However the post-merge run exposed a separate, deterministic failure mode: the auth-ui project's login stalls every time it runs after the setup project finishes. URL trail ends at the hub `/login`; the request log shows no POST for the form submit. Same `loginViaSpa` helper that setup uses successfully in the same run.

Re-applying `test.fixme` so main's CI is not stuck red while PMS-148 chases the root cause (diagnostic-enrichment first, then a focused fix). Test body and harness defenses are unchanged; only the call wrapper and the surrounding comment shift.

#PMS-148