test(login): stop the backoff-guard test racing its own one-second lock #145

wtclaude · 2026-08-12T13:17:21Z

wtclaude commented

2026-08-12 13:17:21 +00:00

This is the red check on #144, and it is not that slice's fault. PR Checks / server-tests failed there on backoffGuard returns a generic 429 while locked out — the only failure in 741 tests, in a file the slice does not touch. #144 was merged before this landed, so it needs its own PR.

A single recordFailure() locks an IP for BASE_MS * 2 ** 0 — exactly one second — and the test then does a real HTTP round trip against that lock. On the runner the round trip took 1,456 ms, the lock had expired, and the guard correctly answered 200:

not ok 222 - backoffGuard returns a generic 429 while locked out
  200 !== 429
  duration_ms: 1456.049477

Five failures lock for sixteen seconds, which is not a race any runner hiccup wins. What the test is actually about — the guard's answer while locked out: generic 429, no username/password hint, a Retry-After header — is unchanged.

It has presumably been latent since the test was written and only shows up when the suite is under enough parallel load; slice 3 added three test files, which is very likely what tipped it over. Green locally (7/7 in that file, 741/741 overall).

AI disclosure

This contribution was AI-assisted (Claude Code).

🤖 Generated with Claude Code

**This is the red check on #144, and it is not that slice's fault.** `PR Checks / server-tests` failed there on `backoffGuard returns a generic 429 while locked out` — the only failure in 741 tests, in a file the slice does not touch. #144 was merged before this landed, so it needs its own PR. A single `recordFailure()` locks an IP for `BASE_MS * 2 ** 0` — **exactly one second** — and the test then does a real HTTP round trip against that lock. On the runner the round trip took **1,456 ms**, the lock had expired, and the guard correctly answered 200: ``` not ok 222 - backoffGuard returns a generic 429 while locked out 200 !== 429 duration_ms: 1456.049477 ``` Five failures lock for sixteen seconds, which is not a race any runner hiccup wins. What the test is actually about — the guard's *answer* while locked out: generic 429, no username/password hint, a `Retry-After` header — is unchanged. It has presumably been latent since the test was written and only shows up when the suite is under enough parallel load; slice 3 added three test files, which is very likely what tipped it over. Green locally (7/7 in that file, 741/741 overall). ### AI disclosure - [x] This contribution was AI-assisted (Claude Code). 🤖 Generated with [Claude Code](https://claude.com/claude-code)

wtclaude added 1 commit 2026-08-12 13:17:23 +00:00

test(login): stop the backoff-guard test racing its own one-second lock

PR Checks / bot-install (pull_request) Successful in 15s

Details

PR Checks / client-build (pull_request) Successful in 23s

Details

PR Checks / server-tests (pull_request) Successful in 8m57s

Details

ec2b530be7

A single recordFailure() locks for BASE_MS * 2 ** 0 — exactly one second — and
the test then does a real HTTP round trip against it. On CI that round trip took
1,456 ms and the guard correctly answered 200, failing the run for a reason that
has nothing to do with what the test is about.

Five failures lock for sixteen seconds. The subject is the guard's answer while
locked out, which is unchanged.

Co-Authored-By: Claude <noreply@anthropic.com>

whitlocktech merged commit 12df79430f into edge

2026-08-12 13:39:52 +00:00

whitlocktech deleted branch fix/login-backoff-flake

2026-08-12 13:39:53 +00:00

whitlocktech referenced this issue from a commit

2026-08-12 13:39:54 +00:00

Merge pull request 'test(login): stop the backoff-guard test racing its own one-second lock' (#145) from fix/login-backoff-flake into edge

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: RunicGateway/website#145