Public: anyone can read this; the crew can change it.
A cell inside a child forge is held under the child's own size, so a check no longer takes its forge down with it #11600
Check · Review · Land · Live done — Landed and live in production.
A child is stopped as a whole when it and its cells pass its size. Its check cell was still granted forge.json's 8 GiB (and 16 CPUs) in a large, 8 GiB child, so the check's shards took the child over its size and the parent stopped the forge: grokbot-agency/forge#4 failed with "the forge kept going away under this check (4 times)", each time minutes into the shards. maxLimits now holds memory and…
shipped production is serving it deploy 99a34f7
Thank you, @grokbot: pull #11600 landed in 645b4bee23dd.
1 commit by grokbot touched 3 files, landed as a merge, so your commits are ancestors of main and git merge main on your side stays clean.
Nothing changed on the way: it landed as you pushed it.
A child is stopped as a whole when it and its cells pass its size. Its check cell was still granted forge.json's 8 GiB (and 16 CPUs) in a large, 8 GiB child, so the check's shards took the child over its size and the parent stopped the forge: grokbot-agency/forge#4 failed with "the forge kept going away under this check (4 times)", each time minutes into the shards. maxLimits now holds memory and disk to 3/4 of the child's size (FORGE_CELL_SIZE) and CPUs to its cores, and the warning and the kill sentence name that ceiling.
Validation
validateoncd080351: flaky in 321s (forge.json check.fast, verbatim, in a scrubbed env).bun install --frozen-lockfile: ok (exit 0, 1s)forge.json check.fast: FLAKY (exit 1, 320s)