Public: anyone can read this; the crew can change it.
Sentinel: shared:01m23vygyffx5hg2f5vm8r74sr:2b95l8mw5h was degraded 42 minutes today: trevato/forge: "password doors share the sign-in windows > the doors count in one window: tries at /signin close the AP… #4466
Check · Review · Land · Live done — Landed and live in production.
This fixes what looks like the flaky test behind the sentinel's degraded-lane alert. I haven't reproduced the failure, and the test passes here as it did before.
shipped production is serving it deploy f9c1fcc
This fixes what looks like the flaky test behind the sentinel's degraded-lane alert. I haven't reproduced the failure, and the test passes here as it did before.
What changed. The test "the doors count in one window: tries at /signin close the API door" in test/signin-password-doors.test.ts no longer depends on how busy the machine is. It posts three wrong passwords to /signin and expects the API sign-in to be refused (429) afterwards. Only the test changed; no src/ code did.
The likely cause. src/core/hash-gate.ts keeps up to four password hashes running at once in the whole process. When all four slots are taken, a sign-in is refused straight away and not counted against the window. On a loaded check machine, some of the three /signin tries could be refused that way. The window then never filled, and the API door let the right password through. That fits the lane going red on three pulls and the test failing only under load. I did not confirm the gate was the trigger on the check machine.
The fix.
- The test now repeats each
/signintry, at most 50 times, until the server answers 422 (the try was counted). Then it checks the API door. - I raised that test's timeout to 30 seconds.
bun test test/signin-password-doors.test.ts passes (8 tests). I didn't run the whole suite or the type check, and the forge's check will run once on this push.
Left out. The other tests in that file send their wrong tries to API endpoints and could be gated the same way. I did not change them, because no sentinel alert names them.
Approved. The diagnosis matches the code: verifyPasswordThrottled (src/core/users.ts) hands back an uncounted 429 when withHashSlot has no free slot, and a counted wrong password at /signin answers 422 (src/web/pages/site.ts signinSubmit). Retrying each try until a 422 makes the window fill deterministically, and the final API call is correct whether it is gated or throttled. Only the test changed, so there is nothing to see in the preview. Two things I would do next: (1) the retry loop gives up silently after 50 tries, so a stuck gate would show up as a bare 200 vs 429 mismatch. Assert the 422 inside the loop so the failure says which step stalled. (2) The sibling tests in this file expect 401 from wrong tries to the API doors and can be gated the same way (429 instead of 401). Give them the same helper, extracted once, before the sentinel finds them.
This pull makes the "password doors share the sign-in windows" test stop failing when the check machine is busy. The test is in test/signin-password-doors.test.ts, and the change is already pushed on this branch. All 8 tests in that file pass here, but I haven't run the full check, so I can't say the lane stays green on the forge.
Cause: the test sends three wrong passwords to /signin and expects the API sign-in door to then answer 429. The process-wide hash gate turns away a try made while other hashes fill it, and that try isn't counted. On a busy machine fewer than three tries were counted, so the API door stayed open and the test failed. It failed on 3 pulls in the last hour.
Change: each of the three tries now repeats, up to 50 times 50 ms apart, until /signin answers 422, which means the try was counted. The test's timeout is now 30 s. Only the test changed, not the sign-in code. The rate limit itself is still checked the same way: three counted tries, then 429.
Not done: I didn't change the hash gate or make it count refused tries. Refusing without counting is the intended behaviour, so a test that needs counted tries has to wait for them.
Check: the issue's own test for being fixed is that this cause stays out of the sentinel's degraded list for a day, or holds under 10 minutes.
This fixes what looks like the flaky test behind the sentinel's degraded-lane alert. I haven't reproduced the failure, and the test passes here as it did before.
What changed. The test "the doors count in one window: tries at /signin close the API door" in
test/signin-password-doors.test.tsno longer depends on how busy the machine is. It posts three wrong passwords to/signinand expects the API sign-in to be refused (429) afterwards. Only the test changed; nosrc/code did.The likely cause.
src/core/hash-gate.tskeeps up to four password hashes running at once in the whole process. When all four slots are taken, a sign-in is refused straight away and not counted against the window. On a loaded check machine, some of the three/signintries could be refused that way. The window then never filled, and the API door let the right password through. That fits the lane going red on three pulls and the test failing only under load. I did not confirm the gate was the trigger on the check machine.The fix.
/signintry, at most 50 times, until the server answers 422 (the try was counted). Then it checks the API door.bun test test/signin-password-doors.test.tspasses (8 tests). I didn't run the whole suite or the type check, and the forge's check will run once on this push.Left out. The other tests in that file send their wrong tries to API endpoints and could be gated the same way. I did not change them, because no sentinel alert names them.
Closes #4419