Public: anyone can read this; the crew can change it.
"GET /signin names its phases and answers within its budget" passes every time on a loaded check machine #5225
Check · Review · Land · Live done — Landed and live in production.
This makes `GET /signin names its phases and answers within its budget` (and the `/signup` twin) stop failing on a loaded machine. The source is untouched, since this was a measurement flake and not a race.
shipped production is serving it deploy da65c36
Test-only change; the flaky single sample becomes best-of-7, the same technique baselineMs already uses in test/helpers/budget.ts. Phase-name assertions still run on every sample, the 200 check too, and the budget is still enforced on the best sample, so a genuinely slow handler still fails. No security, tty or dependency surface touched; no src/web change, so the preview is unaffected. Two things I would do next: (1) lift the best-of-N sampling into helpers/budget.ts so other timing tests can share it instead of copying the loop; (2) move the phase-name format check out of the loop (once is enough) to keep the loop about timing only.
This makes
GET /signin names its phases and answers within its budget(and the/signuptwin) stop failing on a loaded machine. The source is untouched, since this was a measurement flake and not a race.Cause: the test judged one request's
app;durfrom Server-Timing against a 10 ms budget. That figure is wall clock from dispatch to response, so when other cells compete for the CPU and the event loop stalls mid-request, a single sample inflates. The budget guards the handler's own cost, but one noisy sample measured the machine.Change:
test/signin-timing.test.tsnow takes seven requests after the warm-up. Each one still asserts status 200 and thatappplus every named phase is present in thename;dur=N.Nformat. The budget is checked against the fastestappduration. The 10 ms budget and theexpectBudgetbaseline logic are unchanged, so nothing got wider. If the handler itself regresses, every sample is slow and the test still fails.Checked:
bun test --rerun-each 30 test/signin-timing.test.tsgave 60 pass, 0 fail.bun test test/signin-timing.test.ts test/apps.test.tsgave 23 pass, 0 fail. I didn't run any test with deliberately slowed code, so "still fails when the handler regresses" rests on the reasoning above.Left out: I didn't switch to summing the phase durations or touch
test/helpers/budget.ts. Both are still wall clock, so they wouldn't remove the noise.Closes #5197