fix(e2e): give hub-login setup backoff headroom for 2FA rate limit #285

Merged
Claude-Run merged 1 commit from fix/BUNYIP-276-e2e-setup-2fa-backoff-headroom into main 2026-06-30 06:18:11 +02:00
Member

The setup project (global.setup.ts) drives the same loginViaHub as the auth-ui login.spec, which since BUNYIP-267 waits out and resubmits past bunyip's login rate-limit windows: the /login per-email 5/min window and the /login/2fa per-IP 2fa_verify:{ip} 5/min window. The latter is keyed by source IP and shared across every E2E run on the same CI runner, so closely-spaced runs exhaust it and bunyip re-renders /login/2fa with "Too many requests. Please wait N seconds." A single backoff is ~27s.

login.spec already calls test.slow() to give that backoff room inside the 60s per-test budget. The setup project did not, even though it runs the same login on a longer path (it then drives the OIDC consent + token-capture flow), so a rate-limit backoff could trip the 60s timeout mid-wait. This is exactly the shape of run #1326, which failed in global.setup.ts -> loginViaHub at /login/2fa with "Too many requests. Please wait 26 seconds."

Add setup.slow() at the top of the setup body so the login backoff has the same 3x headroom the auth-ui login already has. Verified with tsc --noEmit (strict, exit 0) and playwright test --list (exit 0, setup test collected).

#BUNYIP-276

The `setup` project (global.setup.ts) drives the same loginViaHub as the auth-ui login.spec, which since BUNYIP-267 waits out and resubmits past bunyip's login rate-limit windows: the /login per-email 5/min window and the /login/2fa per-IP `2fa_verify:{ip}` 5/min window. The latter is keyed by source IP and shared across every E2E run on the same CI runner, so closely-spaced runs exhaust it and bunyip re-renders /login/2fa with "Too many requests. Please wait N seconds." A single backoff is ~27s. login.spec already calls test.slow() to give that backoff room inside the 60s per-test budget. The setup project did not, even though it runs the same login on a longer path (it then drives the OIDC consent + token-capture flow), so a rate-limit backoff could trip the 60s timeout mid-wait. This is exactly the shape of run #1326, which failed in global.setup.ts -> loginViaHub at /login/2fa with "Too many requests. Please wait 26 seconds." Add setup.slow() at the top of the setup body so the login backoff has the same 3x headroom the auth-ui login already has. Verified with `tsc --noEmit` (strict, exit 0) and `playwright test --list` (exit 0, setup test collected). #BUNYIP-276
fix(e2e): give hub-login setup backoff headroom for 2FA rate limit
All checks were successful
E2E / Playwright against deployment (pull_request) Successful in 20s
Check / fmt + clippy + build + tests (pull_request) Successful in 14m5s
Create release / Create release from merged PR (pull_request) Has been skipped
cc9eb1e4df
The `setup` project (global.setup.ts) drives the same loginViaHub as the auth-ui login.spec, which since BUNYIP-267 waits out and resubmits past bunyip's login rate-limit windows: the /login per-email 5/min window and the /login/2fa per-IP `2fa_verify:{ip}` 5/min window. The latter is keyed by source IP and shared across every E2E run on the same CI runner, so closely-spaced runs exhaust it and bunyip re-renders /login/2fa with "Too many requests. Please wait N seconds." A single backoff is ~27s.

login.spec already calls test.slow() to give that backoff room inside the 60s per-test budget. The setup project did not, even though it runs the same login on a longer path (it then drives the OIDC consent + token-capture flow), so a rate-limit backoff could trip the 60s timeout mid-wait. This is exactly the shape of run #1326, which failed in global.setup.ts -> loginViaHub at /login/2fa with "Too many requests. Please wait 26 seconds."

Add setup.slow() at the top of the setup body so the login backoff has the same 3x headroom the auth-ui login already has. Verified with `tsc --noEmit` (strict, exit 0) and `playwright test --list` (exit 0, setup test collected).

#BUNYIP-276
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!285
No description provided.