fix(e2e): JMAP origin + share one disposable account for mail flows (BUNYIP-150) #221
Loading…
Reference in a new issue
No description provided.
Delete branch "fix/bunyip-150-jmap-origin-and-register-budget"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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
apiUrlas 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/jmapGET already succeeds over the public TLS host, sojmapSessionnow 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.tsthat registers one account inbeforeAlland 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: 0so a failure can't re-runbeforeAlland 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 --noEmitclean.playwright test --list: the three flows collect underemail-flows.spec.ts(auth-ui).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_limitsrows for the runner IP on the staging DB (actionregistration), or wait out the hour. After this change each run uses only 1 registration, so reruns are sustainable.Pull request closed