A loop stall that no request ran across names the background job that was running #10845

A loop stall that no request ran across is now counted against the background job that was running. none is left only when nothing named was running.

• src/perf/jobs.ts (new): during(name, fn) marks a job as running until its body returns, or until its promise settles if it is async. A throw ends the job and is passed back to the caller. Each call does one map write and fills one slot in a fixed ring of 256 finished jobs. across(from, to) returns the jobs whose run overlaps a stall window, longest first.
• src/perf/loop.ts: Stall gets a jobs field. The jobs are looked up only when no request overlaps the stall, so request attribution and the per-request path are unchanged. The tally, GET /metrics and /system count these stalls as route="job:<name>", so a job cannot be mistaken for a route. The log line reads running then: no request; jobs <names>. The lag;dur header is untouched.
• src/perf/live.ts: the process's loop watch reads the process's job watch.
• Wrapping only: every inline setInterval body in src/main.ts now runs under a stable name: flag-uses, delivery, sync, ahead, guard-sweep, follow, asks, holds, model-review, week, nightly-scan, processes, release-behind, landings, release-keeper, roll-probe, lease. So do the standing-sweep timer in src/http/server.ts and the feature-schedule and pull-schedule ticks.
• test/perf-loop-jobs.test.ts: a job that busy-blocks for 300 ms is named in the tally and the stall line, and an idle stall with no request and no job running is still none. It also covers an async job running until its promise settles, a throwing job, and a request taking the blame ahead of a job.

Left out: the jobs that the start* helpers in src/main.ts start inside their own modules (startNightly, startChecks' lane, startSampler, startCrew, startKeeper, startClogTick and others) are not wrapped yet. The issue limits main.ts to wrapping, and those timers live in their modules; each needs a one-line during(...) around its tick body, and that suits a follow-up. An async job counts as running across its awaits as well as its synchronous parts. That matches "for as long as its sync or async body runs", but it can name a job that was only waiting on I/O during the stall.

Checks: bun x tsc --noEmit and bun scripts/gate.ts pass. scripts/fast.ts named almost the whole suite because server.ts changed, so I ran the 15 test files covering the loop, stall, schedule, metrics and server-hook code: 88 pass. A broader run I started by mistake took in the whole suite, and in this sandbox thousands of its tests fail because the network is blocked, so it says nothing about this change. The forge's check runs the full suite on push.

Try it: after a slow background tick, open GET /metrics and read forge_loop_stall_milliseconds_total{route="job:<name>"}, or look for jobs <name> in the loop log lines.

🤖 Generated with Claude Code

Closes #10834

A loop stall that no request ran across is now counted against the background job that was running. none is left only when nothing named was running.

• src/perf/jobs.ts (new): during(name, fn) marks a job as running until its body returns, or until its promise settles if it is async. A throw ends the job and is passed back to the caller. Each call does one map write and fills one slot in a fixed ring of 256 finished jobs. across(from, to) returns the jobs whose run overlaps a stall window, longest first.
• src/perf/loop.ts: Stall gets a jobs field. The jobs are looked up only when no request overlaps the stall, so request attribution and the per-request path are unchanged. The tally, GET /metrics and /system count these stalls as route="job:<name>", so a job cannot be mistaken for a route. The log line reads running then: no request; jobs <names>. The lag;dur header is untouched.
• src/perf/live.ts: the process's loop watch reads the process's job watch.
• Wrapping only: every inline setInterval body in src/main.ts now runs under a stable name: flag-uses, delivery, sync, ahead, guard-sweep, follow, asks, holds, model-review, week, nightly-scan, processes, release-behind, landings, release-keeper, roll-probe, lease. So do the standing-sweep timer in src/http/server.ts and the feature-schedule and pull-schedule ticks.
• test/perf-loop-jobs.test.ts: a job that busy-blocks for 300 ms is named in the tally and the stall line, and an idle stall with no request and no job running is still none. It also covers an async job running until its promise settles, a throwing job, and a request taking the blame ahead of a job.

Left out: the jobs that the start* helpers in src/main.ts start inside their own modules (startNightly, startChecks' lane, startSampler, startCrew, startKeeper, startClogTick and others) are not wrapped yet. The issue limits main.ts to wrapping, and those timers live in their modules; each needs a one-line during(...) around its tick body, and that suits a follow-up. An async job counts as running across its awaits as well as its synchronous parts. That matches "for as long as its sync or async body runs", but it can name a job that was only waiting on I/O during the stall.

Checks: bun x tsc --noEmit and bun scripts/gate.ts pass. scripts/fast.ts named almost the whole suite because server.ts changed, so I ran the 15 test files covering the loop, stall, schedule, metrics and server-hook code: 88 pass. A broader run I started by mistake took in the whole suite, and in this sandbox thousands of its tests fail because the network is blocked, so it says nothing about this change. The forge's check runs the full suite on push.

Try it: after a slow background tick, open GET /metrics and read forge_loop_stall_milliseconds_total{route="job:<name>"}, or look for jobs <name> in the loop log lines.

🤖 Generated with Claude Code

A loop stall that no request ran across is now counted against the background job that was running, as forge_loop_stall_milliseconds_total{route="job:<name>"} on /metrics, and the stall finding line names it (no request; jobs <name>). If no named job ran across the stall, it is still counted under none.

How a job is matched to a stall (src/perf/jobs.ts)

• during(name, fn) marks the job as blocking only while fn runs synchronously.
• If fn returns a promise, the job is then awaiting until the promise settles. Awaiting doesn't hold the loop.
• across(from, to) returns the jobs whose blocking slice overlaps the stall, longest first. Awaiting jobs are named only when no job was blocking across it. In that case the stall most likely came from code that ran after one of their awaits, so the name is a lead, not a proof.
• A job can mark code that runs after an await by calling during again inside it. That nested slice counts as blocking.

Which jobs are wrapped

• Every timer and scheduler tick in main.ts, including the first passes at boot: sync, guard-sweep, delivery, asks, processes, landings, release-behind, release-keeper.
• The ticks inside the start* helpers: lane, verify-sweep and lane-catch-up (checks), crew and clone-sweep, nightly, sampler, memory-sampler, keeper, clog, looks, mirror-pulls, perf-watcher, probes, snapshot, drill, snapshot-mirror, notify and notify-page, prompts, heartbeat, reach, upstream.

Job names are fixed strings, so the label stays a small, fixed set.

Tests (test/perf-loop-jobs.test.ts)

• When one job is awaiting and another blocks, only the blocking job is named, both by across and in the loop tally.
• An awaiting job is named only when nothing blocked.
• The process's loopWatch in src/perf/live.ts reads the process's job watch: a during call from jobs.ts shows up in loopWatch.tally.

Checks run: bun scripts/gate.ts and bun x tsc --noEmit pass. scripts/fast.ts found the diff too broad to name tests, so I ran the tests for the touched modules: the loop and stall tests, crew tick, flow keeper, mirror pulls, nightly, notify, probes, prompts, snapshot drill and memory ceiling. All pass except one: prompts from Instagram > nothing before the hour; once after it; not again the same day in test/prompts.test.ts. It fails the same way with my changes stashed, so it was already failing on the base.

The main.ts timers I wrapped earlier are now wrapped across several lines, as the file does elsewhere.

Not done: one-off timers inside request handlers are not wrapped, and jobs that already exist do not yet mark the code that runs after their awaits.

To try it: open /metrics on the preview after a slow background tick and read forge_loop_stall_milliseconds_total{route="job:<name>"}.

🤖 Generated with Claude Code