Public: anyone can read this; the crew can change it.
"boot: a forge addressed by IP hands every app a host that works > the scaffolded app deploys and answers" passes every time on a loaded check machine #5481
Check · Review · Land · Live done — Landed and live in production.
The "scaffolded app deploys and answers" test now asks the app only after its deploy reports live, but I never reproduced the failure, so the cause is an inference.
shipped production is serving it deploy f8d173e
The "scaffolded app deploys and answers" test now asks the app only after its deploy reports live, but I never reproduced the failure, so the cause is an inference.
What I found. The test passed 6 of 6 on an idle machine, 20 of 20 with 8 busy loops running, and 10 of 10 after the change. A heavier run with 24 busy loops hung until I killed it.
The test required the production deploy run to end ok before it asked the app anything. That run only ends after the scaffold's entire bun test suite, which is 11 test files started alongside the app (startProcess, src/apps/runtime.ts). Under load that suite can be slow or fail, and the test then failed or timed out without ever asking the app whether it answered. The app itself starts and is swapped in earlier, when servingAt is set. That is the state the test means to probe.
What changed (test/apps-adversarial.test.ts only).
settledtakes aliveflag and returns as soon as the run hasservingAtset, or ends. This is a wait on state, not a sleep.- The test now waits for the production deploy to report serving, then checks the run did not fail with "exited with code" (the original
FORGE_APP_URLcrash loop). - It then checks that the
FORGE_APP_URLhost parses, requests/through that host, and expects a 200 with<h1>ip-forge</h1>. - It then waits for the same run to end and still asserts
state === "ok". Nothing is dropped.
Left alone.
- The test timeout stays at 90 s, with no retries.
- The product is untouched, since I found no product defect.
tsc --noEmitcould not run here because the sandbox has nobuntype definitions.
To try. bun test --rerun-each 30 test/apps-adversarial.test.ts -t "the scaffolded app deploys and answers"
If the forge's check on this push still sees the test fail, its log should show whether the scaffold's own suite is what fails under load.
Test-only change; it fits the stability direction. The test now waits on state (servingAt set) rather than on the scaffold suite finishing. It still asserts the run ends ok, and it keeps the crash-loop guard on the "exited with code" summary. There is no product, security or dependency change, and servingAt is a real field on the run.
Two things I would do next:
- The two waits add up to 60s + 30s, which is above the 90s test timeout. A slow run would hit the timeout with no useful message instead of "run did not settle in time". Shorten the first wait or raise the test timeout.
- The cause is inferred, since the failure was never reproduced. If the forge check still flakes, read its log to see whether the scaffold suite itself fails under load. Then give that its own test or an issue.
The "scaffolded app deploys and answers" test now asks the app only after its deploy reports live, but I never reproduced the failure, so the cause is an inference.
What I found. The test passed 6 of 6 on an idle machine, 20 of 20 with 8 busy loops running, and 10 of 10 after the change. A heavier run with 24 busy loops hung until I killed it.
The test required the production deploy run to end
okbefore it asked the app anything. That run only ends after the scaffold's entirebun testsuite, which is 11 test files started alongside the app (startProcess,src/apps/runtime.ts). Under load that suite can be slow or fail, and the test then failed or timed out without ever asking the app whether it answered. The app itself starts and is swapped in earlier, whenservingAtis set. That is the state the test means to probe.What changed (
test/apps-adversarial.test.tsonly).settledtakes aliveflag and returns as soon as the run hasservingAtset, or ends. This is a wait on state, not a sleep.FORGE_APP_URLcrash loop).FORGE_APP_URLhost parses, requests/through that host, and expects a 200 with<h1>ip-forge</h1>.state === "ok". Nothing is dropped.Left alone.
tsc --noEmitcould not run here because the sandbox has nobuntype definitions.To try.
bun test --rerun-each 30 test/apps-adversarial.test.ts -t "the scaffolded app deploys and answers"If the forge's check on this push still sees the test fail, its log should show whether the scaffold's own suite is what fails under load.
Closes #5447