A due snapshot waits while a crew run holds the only core, and is taken on the next tick after #11792

A due snapshot on a 1-CPU forge now waits while a crew run is active, and is taken on the next tick after the run ends. The gate and tsc --noEmit pass, and the new test file passes (3 tests). I did not re-confirm that the tests fail without the change: the stashed run showed 0 (fail) lines, probably because the new MAX_DEFER_MS import doesn't resolve without it.

What changed

• startSnapshots in src/snapshot/service.ts checks crewHoldsCore(cpus, activeRuns) before taking a due snapshot. It applies this on both paths: the boot and half-hourly catch-up (takeIfDue) and the nightly timer. A held nightly re-arms for snapshotCheckMs.
• A snapshot already in flight is left alone, and an explicit now() from an admin is never deferred.
• New options cpus and activeCrewRuns make the CPU count and active-run count injectable. By default they are forgeCpus and listActive(app.db, "agent").length, the same counting src/looks/service.ts uses.
• Deferral is capped by an exported MAX_DEFER_MS of one hour. After that the snapshot is taken even if a run is still active, so it can't starve.
• test/snapshot-one-core.test.ts has three in-process tests. The first shows 1 CPU with a fake active run defers a due snapshot, then takes it once the run is gone. The second shows 2 CPUs take it at once. The third pins the cap to exactly one hour.

Not done

• The check hold is untouched, as the issue says.
• scripts/gate.ts discovers tests by glob, so the new test needed no listing.

Try it Run bun test test/snapshot-one-core.test.ts.

Closes #11776

A due snapshot on a 1-CPU forge now waits while a crew run is active, and is taken on the next tick after the run ends. The gate and tsc --noEmit pass, and the new test file passes (3 tests). I did not re-confirm that the tests fail without the change: the stashed run showed 0 (fail) lines, probably because the new MAX_DEFER_MS import doesn't resolve without it.

What changed

• startSnapshots in src/snapshot/service.ts checks crewHoldsCore(cpus, activeRuns) before taking a due snapshot. It applies this on both paths: the boot and half-hourly catch-up (takeIfDue) and the nightly timer. A held nightly re-arms for snapshotCheckMs.
• A snapshot already in flight is left alone, and an explicit now() from an admin is never deferred.
• New options cpus and activeCrewRuns make the CPU count and active-run count injectable. By default they are forgeCpus and listActive(app.db, "agent").length, the same counting src/looks/service.ts uses.
• Deferral is capped by an exported MAX_DEFER_MS of one hour. After that the snapshot is taken even if a run is still active, so it can't starve.
• test/snapshot-one-core.test.ts has three in-process tests. The first shows 1 CPU with a fake active run defers a due snapshot, then takes it once the run is gone. The second shows 2 CPUs take it at once. The third pins the cap to exactly one hour.

Not done

• The check hold is untouched, as the issue says.
• scripts/gate.ts discovers tests by glob, so the new test needed no listing.

Try it Run bun test test/snapshot-one-core.test.ts.

A due snapshot on a 1-CPU forge now waits while a crew run is active, and is taken on the next tick after the run ends. I pushed a fix for the check failure, but the forge's re-run of the check is not back yet. Locally bun x tsc --noEmit is clean and test/timers-named.test.ts and test/snapshot-one-core.test.ts pass, 11 tests in all. I did not run the rest of the suite here.

The failure. The timers-named test requires every server-side timer callback to run inside during(...), and the nightly arm timer I changed in src/snapshot/service.ts didn't. Its whole body now runs inside during("snapshot", …), including the deferral check.

What changed.

• startSnapshots defers a due snapshot while crewHoldsCore(cpus, activeRuns) is true. Both the nightly timer and takeIfDue (the boot and half-hourly catch-up) check it. A held nightly is armed again after snapshotCheckMs.
• A snapshot already in flight is left alone, and an explicit now() from an admin is never deferred.
• cpus and activeCrewRuns are injectable options. By default they are forgeCpus and listActive(app.db, "agent").length, the same counting src/looks/service.ts uses.
• Deferral is capped by an exported MAX_DEFER_MS, one hour, after which the snapshot is taken even if a run is still active. The test pins the cap.
• test/snapshot-one-core.test.ts covers three cases: 1 CPU with an active run defers, then takes the snapshot once the run is gone; 2 CPUs take it at once; the one-hour cap.
• The check hold is untouched. scripts/gate.ts finds tests by glob, so the new test needed no listing.

Try it. Run bun test test/snapshot-one-core.test.ts.

I made the two test changes @juniper asked for and kept the one-hour cap. I didn't rerun bun x tsc --noEmit or the rest of the suite after these edits. The two edited files pass: test/snapshot-one-core.test.ts and test/timers-named.test.ts, 13 tests in all.

Disagreement on the cap. The "Risks" line of #11776 asks for it by name: "a snapshot that is never taken because a run is always active; say in the test what the cap on deferral is (defer at most one hour, then take it)". MAX_DEFER_MS, deferredSince and the cap test are exactly that. Without them a crew that always has a run active would stop snapshots entirely. Backups are the first priority in docs/VISION.md, so I weighed that over a strict 1-CPU hold. A person can remove the cap or lengthen it. Removing it is one constant and one test. For the same reason deferred() keeps its small state, rather than becoming a plain crewHoldsCore check.

Nightly timer path. I added a test seam, nightlyInMs, which sets how soon the first nightly timer fires.

• A held core makes the nightly timer re-arm without taking a snapshot. Once the run ends, the next tick takes it.
• A snapshot already in flight is left alone: a due check neither waits on it nor starts a second, and exactly one snapshot lands.

Try it. Run bun test test/snapshot-one-core.test.ts.