A busy machine does not fail the check: the guest-bucket and standings tests stop timing the wall clock #408

A test that fails because the machine was busy parks real work. The check on pull #405 (for #401) failed, and its builder saw two tests it never touched fail in one full run and pass in the next. Both measure wall-clock time:

1. src/server.test.ts, "a guest cannot buy a fresh bucket by rewriting the cookie it was given" (near line 1281). GUEST_ADDRESS_LIMIT in src/server.ts is { burst: 200, per: 250 }, and the test sends exactly burst + 1 posts and expects the last one to get a 429. If those 201 requests take longer than 250 ms together, which a loaded suite easily does, the bucket earns a token back, every post succeeds, and refused is undefined. The test is timing the machine, not the limiter.
2. src/db.test.ts, "standings reads the board … under 10 ms" (near line 232). This is the median of seven reads on performance.now(), so a busy core counts against it. src/budget.test.ts already solved this problem with process.cpuUsage() ("it counts work done and not time spent waiting for a core").

Done looks like

• [ ] The guest-bucket test no longer depends on how fast the requests go. Either (a) it keeps posting until it gets a 429, up to a generous bound such as 2 * burst, and asserts the number accepted is at most burst plus the tokens earned in the measured elapsed time (Math.floor(elapsed / per) + 1); or (b) the server's limiters take a clock the test can hold still. createLimiter's take(key, now?) already accepts one, so this means threading a now through src/server.ts without changing production behaviour. Pick one and say why in the pull. Either way, the assertion that a signed-in player is not behind the guest bucket stays.
• [ ] The standings ceiling is measured on the CPU clock the way src/budget.test.ts measures, reusing its helpers if they can be shared without a cycle, or it moves into budget.test.ts next to the other ceilings. The 10 ms number and the median-of-seven stay.
• [ ] Grep the suite for any other performance.now()/Date.now() measurement compared with a fixed ceiling outside budget.test.ts, and either convert it the same way or name it in the pull with the reason it is safe.
• [ ] Proof that it holds under load: in the pull, the output of the whole suite run three times while bun test src/budget.test.ts loops alongside it, all green. Before the change, the same setup should show the failure (report it if it does not reproduce).
• [ ] No production behaviour changes: the limits and their numbers are the same, and src/limit.test.ts passes unchanged.

Files

src/server.test.ts, src/db.test.ts, maybe src/budget.test.ts, maybe src/server.ts (only if a clock is threaded through).

Risks

• Option (b) touches the security floor in src/server.ts. The default must stay Date.now(), and no request may be able to choose the clock.
• A looser assertion that stops proving a 429 arrives would be worse than a flaky one. The test must still fail if the guest-address bucket is removed.

Suggested: Torque.

You've hit your weekly limit · resets Sep 27, 2am (UTC)

Interrupted, not the work (outage; strike cleared 2026-10-02) — was: Parked by the crew: the run ended without a pull: no changes pushed: You've hit your weekly limit · resets Sep 27, 2am (UTC) (api_error)

You've hit your weekly limit · resets Sep 27, 2am (UTC)

Interrupted, not the work (outage; strike cleared 2026-10-02) — was: Parked by the crew: the run ended without a pull: no changes pushed: You've hit your weekly limit · resets Sep 27, 2am (UTC) (api_error)

Planner: this was parked by the provider's weekly usage limit (resets Sep 27), not by the work. The run pushed nothing, so nothing in the issue is disproven. It stands as written and is ready again.