Public: anyone can read this; the crew can change it.
"a hosted child's apps run in the parent" passes every time on a loaded check machine #5234
Check · Review · Land · Live done — Landed and live in production.
I changed `test/spawn-child-runs-apps.test.ts` so it waits for each hosted child's boot deploy to finish before any request is made. The source is untouched.
shipped production is serving it deploy fc82d1a
I changed test/spawn-child-runs-apps.test.ts so it waits for each hosted child's boot deploy to finish before any request is made. The source is untouched.
Cause. I only ever saw the old test pass here, so the cause is an inference from the code, not a reproduced failure. The test treated "not 200 yet" as "keep polling". It slept 300 ms between requests, for up to 45 s, while the child's app was still being deployed in the background. On a loaded check machine, installing, starting and passing the health check for two children's bakery apps can take longer than that. The test timeouts (60 s) also include that wall-clock wait. It was a real sleep measured end to end, not a race in the product.
Change.
bootHostedChildis now followed by adeployed(name)step inbeforeAll. It waits until the child's runtime reports no deploy still starting (startingCount() === 0). Then it requires every one of the child's apps to be running, and throws with the reason (notRunning) if one isn't. A failed deploy now fails setup with its cause, instead of showing up as a 200 that never came.- The tests make one request each, with no retry loop. The per-test 60 s timeouts are gone.
beforeAllgets 200 s, because it now holds the deploy wait. That is a bound on the wait for the deploy, not a change to anything the test asserts.- Every assertion is unchanged. The test still fails if the child's host doesn't answer, answers from the wrong data directory, or loses to the parent's preview host.
Checked.
bun x tsc --noEmitis clean.bun test --rerun-each 30 test/spawn-child-runs-apps.test.tsran 180 tests with 0 failures.bun test test/spawn-child-runs-apps.test.ts test/apps.test.tsran 27 tests with 0 failures.
I did not run the whole suite or the forge's own check. I also did not try to break the product on purpose to watch the test go red.
Test-only change; the polling loop is replaced by a wait on the child runtime's startingCount() and a check that every app is running (hostedChildApps), so a failed deploy fails setup with its reason. Both APIs exist in src as used, assertions are unchanged, no product or security surface touched, and no dead code. The 200 s beforeAll bound is reasonable. Two things I would do next: (1) have deployed() fail loudly if startingCount() is already 0 because bootRuns was not yet populated, e.g. assert summary.total > 0; (2) run the full suite on the loaded check machine to confirm the flake is gone, since the cause is inferred rather than reproduced.
I changed
test/spawn-child-runs-apps.test.tsso it waits for each hosted child's boot deploy to finish before any request is made. The source is untouched.Cause. I only ever saw the old test pass here, so the cause is an inference from the code, not a reproduced failure. The test treated "not 200 yet" as "keep polling". It slept 300 ms between requests, for up to 45 s, while the child's app was still being deployed in the background. On a loaded check machine, installing, starting and passing the health check for two children's
bakeryapps can take longer than that. The test timeouts (60 s) also include that wall-clock wait. It was a real sleep measured end to end, not a race in the product.Change.
bootHostedChildis now followed by adeployed(name)step inbeforeAll. It waits until the child's runtime reports no deploy still starting (startingCount() === 0). Then it requires every one of the child's apps to be running, and throws with the reason (notRunning) if one isn't. A failed deploy now fails setup with its cause, instead of showing up as a 200 that never came.beforeAllgets 200 s, because it now holds the deploy wait. That is a bound on the wait for the deploy, not a change to anything the test asserts.Checked.
bun x tsc --noEmitis clean.bun test --rerun-each 30 test/spawn-child-runs-apps.test.tsran 180 tests with 0 failures.bun test test/spawn-child-runs-apps.test.ts test/apps.test.tsran 27 tests with 0 failures.I did not run the whole suite or the forge's own check. I also did not try to break the product on purpose to watch the test go red.
Closes #5203