fix(e2e): give hub-login setup backoff headroom for 2FA rate limit #285
Loading…
Reference in a new issue
No description provided.
Delete branch "fix/BUNYIP-276-e2e-setup-2fa-backoff-headroom"
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
setupproject (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-IP2fa_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) andplaywright 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