fix(switchyard): memoise the machine lookup instead of listing per request

[jhgaylor]

Why

Measured in production on 2026-09-07, the demo apps running on the operator's server key against managoat.com were behind a four-day OOM / DB-pool-exhaustion incident. GET /api/conversations was being called ~50,000 times an hour (14/s); each call returns every conversation on the account (~1,000 rows) and runs an aggregate server-side.

Mechanism (switchyard's share)

• machineOf() and conversationsOf() in server/tracks.ts listed the project's conversations on every call, and are reached from ~25 sites: every file, diff and listing read (tracks.ts), the terminal (terminal.ts), the vitals readout every 20 s per viewer (vitals.ts, src/components/Vitals.tsx), the preview reconciler every 15 s (previews.ts), the shared browser (browsers.ts), the agent preview helper (agent-previews.ts) and the native runner (native-experiment.ts).
• machinesFor() in server/projects.ts listed the whole account unfiltered on every load of the rail (GET /api/projects, GET /api/projects/:id).
• spriteFor() fetched the sandbox on every terminal/vitals/preview call, though a sandbox's sprite never changes.

The track stream (/api/tracks/:id/stream) is an EventSource over a pipe of Fountain's stream, which Fountain holds open with heartbeats, so switchyard was not the source of the 2/s stream reopen rate (that was paddock, #67).

What changed

• New server/machine-cache.ts: the agent-narrowed list is memoised for 5 s per Fountain client and project, concurrent misses share one in-flight promise, and a failed read is not remembered. forgetProject() is called where the answer changes: opening a track (may provision the machine), closing one, rebuild and destroy.
• machineOf() reads from the memo. conversationsOf(), which the sidebar's running/idle status comes from, reads fresh and writes through, so a turn that ended never shows as running for another five seconds, while the burst of machine reads around it is free.
• machineOf(…, { fresh: true }) at the three guards whose whole job is to notice a replaced machine: the preview reconciler's ensureRunning, its readiness check, and the agent helper's grant check. The existing tests for those guards are what caught this.
• spriteFor() memoised for a minute per sandbox id; a "not a sprite" answer for 5 s only.
• machinesFor() makes one memoised, narrowed list per project instead of one unfiltered list of the account.

Not touched: native-experiment.ts (its callers go through machineOf and get the memo; its own replaced-workspace check runs on a session lifecycle rather than per request), the client-side polls (Vitals, previews, shared browser and native preview already pause when the tab is hidden), and the wake-turn readMachine loop in src/lib/api.ts (bounded to 30 s, only after an explicit user action; its per-second reads now hit the memo).

Tests

server/machine-cache.test.ts (7 tests) pins one call per burst and coalescing, expiry, fresh-read write-through, forgetProject, per-client isolation, failures not being remembered, and the two sprite TTLs. Full suite: 396 pass, 1 skip (pre-existing). tsc --noEmit and bun run build are green locally.

🤖 Generated with Claude Code

https://claude.ai/code/session_018R1XyyWd9MDMYXqFL71owk