fix(e2e): JMAP origin + share one disposable account for mail flows (BUNYIP-150) #221

Closed
nrupard wants to merge 549 commits from fix/bunyip-150-jmap-origin-and-register-budget into main
Owner

What

Fix the two failures from the first staging run of the BUNYIP-150 mail-sink specs.

1. JMAP unreachable (the actual bug)

Stalwart's JMAP session document advertises apiUrl as its internal address (http://mail.a8n.run:8080/jmap/), which the CI runner can't reach (ENETUNREACH, and an unroutable IPv6 on :8080). The .well-known/jmap GET already succeeds over the public TLS host, so jmapSession now keeps only the apiUrl path and forces the origin back to the configured sink base (https://mail.a8n.run, Traefik on 443).

2. Registration 429

bunyip caps registration at 3/hour/IP (RateLimitConfig::REGISTRATION). One disposable account per spec was 3 registrations/run - exactly at the cap - and Playwright retries pushed it over (the change-email retries 429'd).

Collapse magic-link + password-reset + change-email into a single serial spec tests/auth/email-flows.spec.ts that registers one account in beforeAll and mutates it through each flow in turn (magic-link is non-destructive; password-reset rotates the password; change-email rotates the email - both tracked for later steps and teardown). retries: 0 so a failure can't re-run beforeAll and burn another registration. One registration per run, leaving head-room for reruns. The three former spec files are removed; the three flows still report as three separate tests.

Verification

  • tsc --noEmit clean.
  • playwright test --list: the three flows collect under email-flows.spec.ts (auth-ui).
  • Full green run needs the live mailbox + secret (already set).

Heads-up: register budget

The failed run already spent the runner IP's 3/hour registration budget, so a rerun within ~1h will 429 on the first register until the window resets. To verify sooner, clear the rate_limits rows for the runner IP on the staging DB (action registration), or wait out the hour. After this change each run uses only 1 registration, so reruns are sustainable.

## What Fix the two failures from the first staging run of the BUNYIP-150 mail-sink specs. ## 1. JMAP unreachable (the actual bug) Stalwart's JMAP session document advertises `apiUrl` as its **internal** address (`http://mail.a8n.run:8080/jmap/`), which the CI runner can't reach (`ENETUNREACH`, and an unroutable IPv6 on :8080). The `.well-known/jmap` GET already succeeds over the public TLS host, so `jmapSession` now keeps only the apiUrl **path** and forces the origin back to the configured sink base (`https://mail.a8n.run`, Traefik on 443). ## 2. Registration 429 bunyip caps registration at **3/hour/IP** (`RateLimitConfig::REGISTRATION`). One disposable account per spec was 3 registrations/run - exactly at the cap - and Playwright retries pushed it over (the change-email retries 429'd). Collapse magic-link + password-reset + change-email into a single serial spec `tests/auth/email-flows.spec.ts` that registers **one** account in `beforeAll` and mutates it through each flow in turn (magic-link is non-destructive; password-reset rotates the password; change-email rotates the email - both tracked for later steps and teardown). `retries: 0` so a failure can't re-run `beforeAll` and burn another registration. **One registration per run**, leaving head-room for reruns. The three former spec files are removed; the three flows still report as three separate tests. ## Verification - `tsc --noEmit` clean. - `playwright test --list`: the three flows collect under `email-flows.spec.ts` (auth-ui). - Full green run needs the live mailbox + secret (already set). ## Heads-up: register budget The failed run already spent the runner IP's 3/hour registration budget, so a rerun within ~1h will 429 on the first register until the window resets. To verify sooner, clear the `rate_limits` rows for the runner IP on the staging DB (action `registration`), or wait out the hour. After this change each run uses only 1 registration, so reruns are sustainable.
fix(e2e): force JMAP origin + share one disposable account for mail flows (BUNYIP-150)
Some checks failed
E2E / Playwright against deployment (pull_request) Failing after 50s
Check / fmt + clippy + build + tests (pull_request) Successful in 4m28s
Create release / Create release from merged PR (pull_request) Has been skipped
ec24addbfa
Two fixes from the first staging run of the mail-sink specs:

1. JMAP unreachable. Stalwart advertises its session apiUrl as the internal address (http://mail.a8n.run:8080/jmap/), which the CI runner cannot reach; the POST followed it and failed with ENETUNREACH. The .well-known/jmap GET already succeeds over the public TLS host, so keep only the apiUrl path and force the origin back to the configured sink base (https://mail.a8n.run via Traefik on 443).

2. Registration 429. bunyip caps registration at 3/hour/IP (RateLimitConfig::REGISTRATION). One disposable account per spec was 3 registrations/run, exactly at the cap, and Playwright retries pushed it over. Collapse magic-link, password-reset, and change-email into a single serial spec (tests/auth/email-flows.spec.ts) that registers ONE account in beforeAll and mutates it through each flow in turn (magic-link is non-destructive; password-reset rotates the password; change-email rotates the email, both tracked for later steps + teardown). retries:0 so a failure cannot re-run beforeAll and burn another registration. One registration per run leaves head-room for reruns. The three former spec files are removed.

Docs updated (README status table, dev-docs sink note).

#BUNYIP-150

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
nrupard closed this pull request 2026-06-25 16:39:54 +02:00
David deleted branch fix/bunyip-150-jmap-origin-and-register-budget 2026-06-28 23:07:16 +02:00
Some checks failed
E2E / Playwright against deployment (pull_request) Failing after 50s
Required
Details
Check / fmt + clippy + build + tests (pull_request) Successful in 4m28s
Required
Details
Create release / Create release from merged PR (pull_request) Has been skipped

Pull request closed

Sign in to join this conversation.
No reviewers
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
psa-systems/bunyip!221
No description provided.