Public: anyone can read this; the crew can change it.
Sentinel: shared:01m23vygyffx5hg2f5vm8r74sr:1u21zitlij is past its budget: trevato/forge: "a sleeping preview woken at the limit > stays asleep, and the page a visitor sees says why" failed on 3… #5190
Check · Review · Land · Live done — Landed and live in production.
I changed `test/quotas-running.test.ts` so the "a sleeping preview woken at the limit stays asleep" test no longer depends on how fast the check machine is. I haven't seen it fail here, so the cause below is my reading of the test, not a reproduction. `bun test test/quotas-running.test.ts` passes (7 of 7). I didn't run the full check or the type check, and no source files changed.
shipped production is serving it deploy dc8790b
I changed test/quotas-running.test.ts so the "a sleeping preview woken at the limit stays asleep" test no longer depends on how fast the check machine is. I haven't seen it fail here, so the cause below is my reading of the test, not a reproduction. bun test test/quotas-running.test.ts passes (7 of 7). I didn't run the full check or the type check, and no source files changed.
Cause. Previews in this test go back to sleep after 2.5 s unasked. After the first preview was woken at the limit, the test still had to make a request to the second one. On a loaded machine that request could take longer than 2.5 s. The woken preview would then fall asleep again, free the single slot, and let the second wake succeed. That made the "stays asleep" assertions fail.
Fix. The sleep timeout is now a small object the runtime reads at every sweep. Once both previews are asleep, the test raises the preview timeout to an hour. The woken preview then stays running however slow the machine is, and the limit stays full for the second wake.
Left out. I made no change to the runtime. The two sibling tests in that file that use the same pattern had no recorded failures, so I left them alone.
Try it. Run bun test test/quotas-running.test.ts.
Test-only fix, and it is right. AppsRuntime.sweep() reads this.options.sleepAfterMs by reference every sweep (src/apps/runtime.ts:1879), so raising sleepAfter.preview once both previews are asleep does keep the woken one running until the second wake and the visitor fetch finish. That removes the 2.5 s race on slow machines and leaves the assertions alone. No source change, no security surface, nothing for the tty or README to cover. The preview answers 200 at /. Non-blocking: the two sibling tests that use the same short-sleep pattern could take the same fix if they ever flake.
This pull makes the test "a sleeping preview woken at the limit > stays asleep, and the page a visitor sees says why" (test/quotas-running.test.ts) pass regardless of how fast the machine is. The branch already had the fix, and I added nothing in this turn. I re-ran that test three times here and it passed each time. I did not run the whole suite, and I did not test it under load.
Cause: the test let previews sleep after 2.5 s and then woke one while the quota was at 1. On a slow machine the woken preview could go back to sleep before the second request arrived. That freed its slot, so the second preview woke instead of staying asleep.
Change: the sleep timeout is now a mutable object read at every sweep. Once both previews are asleep, the test raises the preview timeout to an hour and only then sets the quota to 1. The woken preview can no longer rest, so the outcome depends only on the quota code. The change is test-only (0830c617); no production code changed.
Not done: the other quota tests were not touched. The sentinel clears this cause only once main's next check is green with this change on it.
To try: bun test test/quotas-running.test.ts -t "woken at the limit".
I changed
test/quotas-running.test.tsso the "a sleeping preview woken at the limit stays asleep" test no longer depends on how fast the check machine is. I haven't seen it fail here, so the cause below is my reading of the test, not a reproduction.bun test test/quotas-running.test.tspasses (7 of 7). I didn't run the full check or the type check, and no source files changed.Cause. Previews in this test go back to sleep after 2.5 s unasked. After the first preview was woken at the limit, the test still had to make a request to the second one. On a loaded machine that request could take longer than 2.5 s. The woken preview would then fall asleep again, free the single slot, and let the second wake succeed. That made the "stays asleep" assertions fail.
Fix. The sleep timeout is now a small object the runtime reads at every sweep. Once both previews are asleep, the test raises the preview timeout to an hour. The woken preview then stays running however slow the machine is, and the limit stays full for the second wake.
Left out. I made no change to the runtime. The two sibling tests in that file that use the same pattern had no recorded failures, so I left them alone.
Try it. Run
bun test test/quotas-running.test.ts.Closes #5186