fix(e2e): tolerate login rate limit and harden mail wait #277
Loading…
Reference in a new issue
No description provided.
Delete branch "fix/BUNYIP-267-e2e-login-backoff-mail-hardening"
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?
The Playwright e2e suite (run #1306) failed two specs on harness-timing fragility, not product bugs. The auth-ui login spec hit bunyip's 5/min-per-email login rate limit ("Too many requests. Please wait 2 seconds and try again.") and failed with no retry, and the password-reset spec timed out after 30s waiting for the reset email when the Stalwart relay lagged.
loginViaHub now wraps the credential submit in a backoff loop: a rate-limit error_box is classified (not a credential error), and the helper waits out the interval bunyip names before resubmitting, up to four attempts. A Playwright-level retry cannot do this because re-running the test fires another login POST immediately and deepens the 5/min hole, which is why the auth-ui project keeps retries: 0. The single-attempt logic is split into submitLoginOnce, which now races the 2FA redirect against the error_box so a rate-limit rejection is detected in ~1s instead of after the 2FA wait's full 15s timeout, keeping each retry within the test budget. The login spec is marked test.slow() to give the backoff room.
waitForLink now resolves the JMAP session and polls inside a per-iteration try/catch, so a single transient relay/session hiccup re-polls on the next interval instead of aborting the whole wait, and a timeout reports the last poll error. The password-reset spec re-requests the reset once if the first email has not landed within 40s (two requests stay within the 3/hour PASSWORD_RESET limit) and is marked test.slow() so the doubled wait does not trip the per-test timeout.
#BUNYIP-267