Public: anyone can read this; the crew can change it.
The containment watch stops a cell for CPU only by the new rule: a 1-CPU forge sampled at 1.04 cores keeps running #11613
Sign in to join this conversation.
Public: anyone can read this; the crew can change it.
Part of #11539, split from #11558. Wires the pure rule from the issue this waits for into
tick()insrc/apps/contain.ts, which today callsentry.breach(cpuBreach(...))as soon ascores > limits.cpusover the 30 s window.Done looks like:
startedAt) and since when its windowed cores have been above2 * limits.cpus(overSince, cleared the moment a window reads at or below it).tick()calls the rule fromsrc/apps/cpu_rule.tsinstead ofcores > limits.cpus; the stop line still comes fromcpuBreachand names the hold time it actually measured (e.g. "used 2.4 cores for 300s, over twice its limit of 1"), with the same rounding as the rule.tick()are byte-for-byte the same.test/cpu-breach.test.tsis updated for the new line wording, and one test drives the watch's per-entry state through the rule (a helper exported for the test is fine): 1.04 of 1 for an hour → no stop; 2.5 of 1 for 6 minutes on a 15-minute-old cell → one stop with that line.src/apps/contain.ts,test/cpu-breach.test.ts(andtest/contain.test.tsif an assertion there names the old rule) change. No change to forge.json, budgets or crew files.bun test test/cpu-breach.test.ts test/contain.test.ts test/cpu-rule.test.tsandbun x tsc --noEmitpass in the sandbox before the push.