main red: payment-isolation.spec.ts:113 fails on all 3 browsers after #156 auth-redirect change

[TortoiseWolfe]

main is red: payment-isolation.spec.ts:113 fails on all 3 browsers

Test: tests/e2e/security/payment-isolation.spec.ts:113 — "Payment history shows only own payments" (REQ-SEC-001).

Symptom: on the current main E2E run (e6861e6) it fails on chromium + firefox + webkit (3 failed). The assertion that trips:

expect(hasNoPayments || hasPayments).toBe(true);  // line 157

i.e. after "Loading payment history" hides, the region shows neither the "No payment history" heading nor any [data-payment-item] — an empty/stuck render. Deterministic across browsers ⇒ a real regression, not flake.

Regression window: passed on PR #155's run (2026-07-03 morning). Broke after e6861e6 — #156 "make auth redirects basePath-aware" landed. That PR changed AuthContext.tsx redirect logic; payment-isolation runs a two-user login flow and reads each user's payment history — a redirect/session regression there is the most likely cause of the second context's history never loading.

Suspect: the #156 basePath-aware redirect change interacting with the E2E's multi-context auth (the test opens a second browser context for user B). Worth checking whether the post-login redirect now lands somewhere that leaves the PaymentHistory component unmounted/unhydrated.

Impact: a security/RLS isolation test is red on main — blocks clean merges (e.g. PR #160 PayPal, whose only red check is this same pre-existing failure).

Not caused by: PR #160 (PayPal — diff is PaymentButton only) or concurrent-run interference (runs were serialized by the e2e mutex, no overlap).

[TortoiseWolfe]

Local repro findings — NOT a deterministic code bug; CI-load-sensitive

Reproduced against the live backend on current main (has #156 + #160 + #161):

• Single run: ✅ passes.
• --repeat-each=8, workers=1: ✅ 9/9 pass. Rock-solid locally, no intermittency.

So the test logic is not broken — it passes reliably when the backend is uncontended. Yet the main run failed it on all 3 browsers simultaneously (run 28668070985).

Root cause (evidence-based)

The failure is shared-Supabase-backend contention under concurrent CI load, not a code regression:

• payment-isolation:113 calls getPaymentHistory() (authenticated query). On error it renders PaymentHistory.tsx:154 → alert alert-error "Error loading payment history" — a THIRD state that is neither "No payment history" nor [data-payment-item], so expect(hasNoPayments || hasPayments).toBe(true) fails.
• All 3 browser jobs hit the same Supabase project at the same time → the query gets a transient RLS/Realtime error on all three at once. This is precisely the class of failure documented in CLAUDE.md's "Round 10 / shared-backend" lessons.
• fix(auth): #154 make auth redirects basePath-aware (email confirm bounced to domain root) #156 is the trigger, not the deep cause: it changed session/SIGNED_OUT handling (AuthContext.tsx:218 spurious-SIGNED_OUT suppression) + redirect timing, which shifted when the authed payment query fires — making this test newly sensitive to the pre-existing contention. Its own comment even says Supabase fires spurious SIGNED_OUT "on transient 401/406 from Realtime/RLS."

Proper fix options (pick one)

1. Harden the test — treat the transient error state as a retryable condition: wait for a stable terminal state, or retry the payment-history load, rather than asserting on the first post-loading render. (Smallest, test-only.)
2. Harden PaymentHistory.refetch — auto-retry once on a transient fetch error before surfacing the error alert (helps prod too, not just the test).
3. Both — retry in the component (prod resilience) + a tolerant assertion (test stability).

Recommend (2) as the root-cause fix (a transient payment-history error silently degrading the UI is a real prod UX bug), optionally with (1).