perf(server): reaper sweep decodes only live provider bindings

[tusharbhardwaj-bk]

Problem

ProviderSessionReaper sweeps every 5 minutes. Its bindings phase called directory.listBindings(), which decodes every provider_session_runtime row (two Schema passes plus a provider-kind decode per row, concurrency: "unbounded"), then continued past every stopped one.

In prod, 1,351 of 1,355 rows are stopped. The subagent's journal analysis over 575 sweeps in 48 h:

• sweep p50 157 ms, p90 1.86 s, max 5.3 s;
• the time is almost all bindingsMs;
• all of it on the shared event loop.

Fix

• New fork module provider/liveProviderBindings.expbkt3.ts. It runs SELECT thread_id FROM provider_session_runtime WHERE status <> 'stopped' (a small table, no JSON), then directory.getBinding(id) for just those ids. The bindings keep exactly the shape listBindings returns. On an SQL failure it falls back to listBindings().
• One marked seam at the reaper's call site, using the reaper's existing SQL context.

The decode-everything loop is upstream code, so the cleaner long-term fix is an upstream listBindings({ excludeStopped }). Noted as an upstreaming candidate.

Evidence

Lab benchmark on a VACUUM INTO copy of prod (1,355 rows, 1,352 stopped), 5 calls each:

	rows decoded	ms / call
listBindings (before)	1,355	62, 55, 67, 42, 37
listLiveProviderBindings (after)	3	2, 1, 1, 4, 1

The idle lab is far faster than prod under contention (p90 1.86 s), but the ratio holds.

Tests:

• New liveProviderBindings.expbkt3.test.ts: 300 stopped rows, plus one running and one starting; the result is exactly listBindings().filter(status !== "stopped").
• Existing ProviderSessionReaper.test.ts: all pass (20 total).
• vp run typecheck in apps/server is clean, and the fork-marker check passes.

Model/harness: Claude Opus 5.5 via Claude Code in T3 Code.

🤖 Generated with Claude Code