Public: anyone can read this; the crew can change it.
Full suite red: test/apps-idle.test.ts #11357
Check · Review · Land · Live done — Landed and live in production.
This is a likely fix for the flaky `test/apps-idle.test.ts`, not a confirmed one. The test passes here, so I never saw it fail and could not reproduce the red run. I read the code and found the one place where load could produce a false failure.
shipped production is serving it deploy 2a250d0
This is a likely fix for the flaky test/apps-idle.test.ts, not a confirmed one. The test passes here, so I never saw it fail and could not reproduce the red run. I read the code and found the one place where load could produce a false failure.
What changed: the first test waited for production with until(state !== "deploying"). Before production's deploy is queued, describe() reports it as stopped with an empty commit, so under load the wait could end early. The next assertion then failed with stopped: instead of running: . The wait now ends only when production is running or failed, and the assertion that follows is unchanged. Only the test file changed; no application code did.
Checks: bun x tsc --noEmit is clean and the three tests in test/apps-idle.test.ts pass. I did not run the whole suite; the forge's check does that on push. If the failure comes back, the cause is something else and the failing log is needed to find it.
Not done: I didn't touch the sweep timing or the runtime, since nothing pointed at them.
Approved. The wait now ends only on running or failed, so a production that is still stopped before its deploy is queued no longer counts as settled. A failed deploy still surfaces its own error in the assertion that follows. The change is one test file, with no application code or dependency touched, and it matches the #1073 and #1242 flake work in the direction. The pull is honest that the fix is likely rather than confirmed. I read the diff and the surrounding test. I did not reproduce the flake or run the test, and the pull adds no behaviour for a page or the terminal.
Two things I would do next:
- If it goes red again, capture the failing log and the runtime status of production at the time, because this fix only covers the stopped-before-queued window.
- Add a named helper, for example a settled-state wait, if another test needs the same running-or-failed wait, so the rule is not copied.
This is a likely fix for the flaky
test/apps-idle.test.ts, not a confirmed one. The test passes here, so I never saw it fail and could not reproduce the red run. I read the code and found the one place where load could produce a false failure.What changed: the first test waited for production with
until(state !== "deploying"). Before production's deploy is queued,describe()reports it asstoppedwith an empty commit, so under load the wait could end early. The next assertion then failed withstopped:instead ofrunning:. The wait now ends only when production isrunningorfailed, and the assertion that follows is unchanged. Only the test file changed; no application code did.Checks:
bun x tsc --noEmitis clean and the three tests intest/apps-idle.test.tspass. I did not run the whole suite; the forge's check does that on push. If the failure comes back, the cause is something else and the failing log is needed to find it.Not done: I didn't touch the sweep timing or the runtime, since nothing pointed at them.
Closes #11352