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

working checking now opened this has it
opened this

Part of #11539, split from #11558. Wires the pure rule from the issue this waits for into tick() in src/apps/contain.ts, which today calls entry.breach(cpuBreach(...)) as soon as cores > limits.cpus over the 30 s window.

Done looks like:

  • [ ] Each watched entry records when it started being watched (startedAt) and since when its windowed cores have been above 2 * limits.cpus (overSince, cleared the moment a window reads at or below it).
  • [ ] tick() calls the rule from src/apps/cpu_rule.ts instead of cores > limits.cpus; the stop line still comes from cpuBreach and 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.
  • [ ] Memory, disk and process-count stops are unchanged: their lines and thresholds in tick() are byte-for-byte the same.
  • [ ] test/cpu-breach.test.ts is 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.
  • [ ] Only src/apps/contain.ts, test/cpu-breach.test.ts (and test/contain.test.ts if 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.ts and bun x tsc --noEmit pass in the sandbox before the push.
Sign in to join this conversation.

↑↓ navigate ↵ open ⌘↵ its app esc close

Keyboard shortcuts

Docs