Flaky E2E: payment-isolation 'shows only own payments' intermittently fails on the empty-state assertion

[TortoiseWolfe]

tests/e2e/security/payment-isolation.spec.ts:157 (Payment history shows only own payments) fails intermittently on shard chromium-gen 4/6. Observed failing on two unrelated PRs the same evening (#156 auth-redirect fix, #161 messaging-RLS fix) — neither touches payment rendering — and passing on rerun both times, so it's flaky, not a real regression.

The assertion:

const hasNoPayments = await noPaymentsHeading.isVisible().catch(() => false);
const hasPayments = (await paymentList.count()) > 0;
expect(hasNoPayments || hasPayments).toBe(true);

It requires that EITHER the "No payment history" heading is visible OR at least one payment item is present. It fails when neither is true — i.e. the payment-history section is still mid-load (or in a third state) at the moment of the check. The preceding expect(getByText(/Loading payment history/i)).toBeHidden() is supposed to gate on load completion, but there's evidently a window where loading is hidden yet neither the empty-state heading nor a payment row has rendered.

Likely fix: replace the instantaneous isVisible()/count() snapshot with a Playwright web-first assertion that retries, e.g. await expect(noPaymentsHeading.or(paymentList.first())).toBeVisible(), so the check waits for one of the two terminal states instead of sampling once. Worth confirming the empty-state heading actually renders for a brand-new user with no payments (the storageState fixture user).

Low severity (rerun clears it) but it's a security-labeled test, and a flaky security test erodes trust in the gate — this is a stabilization item, not a feature.

🤖 Generated with Claude Code

[TortoiseWolfe]

Root-caused via the failure trace and fixed in PR #164 — and it's a bigger deal than "flaky": the test is deterministically red on main right now, not intermittent.

What's actually happening: the assertion counts [data-payment-item], but PaymentHistory never rendered that attribute (payments are plain table rows / mobile cards). So the test could only ever pass through the empty-state branch. It flipped red the moment the shared fixture user gained a seeded payment_results row (there's 1 now) — the component correctly renders the table, but the list selector matches nothing, so both branches are false.

Confirmed from the Playwright trace: payment_results query returned 200 with one correctly-scoped row, component rendered the desktop table (not error/loading), no auth leak.

Also confirmed NOT a regression from the #154/#156 auth-redirect work, despite the timing correlation: re-ran E2E on the pre-#156 commit today and it fails the identical assertion on all three browsers. The rerun-passes-sometimes behavior earlier was luck (the fixture user's payment count varying between runs), not true flake.

The earlier hypothesis in the issue body (add a retrying web-first assertion for a load-timing window) was wrong — the load completes fine. The real gap is the missing selector hook. PR #164 adds data-payment-item to the rendered rows.