perf(sessions): resolve members/automations once per list, not per row — /api/sessions 51ms → 32ms (v0.292.1)

[vikasprogrammer]

Follow-up to #530. That PR made the 1.5 s console poll cheap on the wire (a 304 with no body), but the server still paid the whole rebuild before it could decide to send that 304. Measured on the live instawp tenant, a 304 cost exactly as much as a full response:

full response (gzip)             50.6 ms   200   246 KB
304 (unchanged, if-none-match)   49.5 ms   304     0 KB   ← same cost, no payload

Where the time actually went

I profiled listSessions against a snapshot of the live instawp DB (950 sessions, 108k audit rows) rather than guessing. Two of my assumptions were wrong:

• the audit-stamp guard is holding — only 8 of 950 rows re-stamp, 0.8 ms total
• the audit indexes are being used (SEARCH … USING COVERING INDEX idx_audit_run_type)

The cost was the four per-row helpers — spawnedByLabel, sourceKind, runAsLabel, canViewSpawn — each issuing its own SQLite point lookup per row:

queries per poll	~1900
rows they were resolving	14 members + 40 automations

The lookup tables are tiny and bounded. The row count (950, growing) is not.

The change

withRowCache() loads each table once per list call; the helpers read from it. Two queries instead of ~1900.

	before	after
listSessions(owner)	35 ms	14 ms (−60%)
listSessions(no viewer)	43 ms	22 ms
listArchivedSessions	1.5 ms	0.6 ms
GET /api/sessions	51 ms	32 ms
…its idle 304 path	50 ms	30 ms ← runs 40×/min per open tab

Why it can't go stale: the scope is synchronous — no await, so no write can interleave — and nothing inside it mutates members or automations (markCrashed/backfillCosts/stampInsights write term_sessions and the audit log only). Outside a scope the helpers take the old direct-query path verbatim, so every other caller is untouched. It's re-entrant, and the previous scope is restored in a finally so an exception can't strand a stale cache on the instance.

Also: gzip level split by recompression frequency

A static asset is compressed once per build and cached → keeps level 6. Live JSON is recompressed on nearly every poll → drops to level 4. On the 1.2 MB sessions payload: 15.8 ms → 10.1 ms for 5.9% more bytes (level 1 would be 6.5 ms but 18.8% more). Compression had grown to cost more than the rebuild itself.

Verification

Both builds run from identical copies of the live DB (listSessions mutates, so a shared copy would invalidate the comparison), with a same-build control run to establish what varies from wall-clock alone:

=== control: same build twice (what wall-clock alone changes) ===
  → wall-clock noise fields: updatedAt      (the 8 running rows)

=== equivalence: before vs after ===
  internal(no viewer)  rows 950  identical modulo wall-clock (updatedAt) ✓
  owner                rows 950  identical modulo wall-clock (updatedAt) ✓
  admin                rows 950  identical modulo wall-clock (updatedAt) ✓
  member               rows   1  IDENTICAL ✓
  archived(owner)      rows  71  IDENTICAL ✓

canViewSpawn is an authz decision, and the live data can't exercise its member branch — every automation there was created by an owner/admin, who short-circuit to true. So a second harness reassigns the 40 automations across 9 real member accounts and compares the visible session set per member:

  ganesh@instawp.com [member]   21 visible   same ✓
  yogesh@instawp.com [member]  167 visible   same ✓
  … 9 members with non-empty automation-derived sets, all identical
✅ authz identical for every member

Governance 159/159 · tier-A 18/18 · registry 18/18 · idle reaper 18/18 · #530's transport checks still pass · tsc + web build clean.

Still open

• /api/sessions remains unbounded — 950 rows today, and the remaining ~14 ms is now mostly the SELECT * itself plus the tmux liveness poll. Pagination is the structural fix; this was the surgical one.
• The Tasks page still polls /api/sessions on its own 5 s timer on top of the shell's 1.5 s poll.
• main.js is one ~15.7k-line App.tsx with no code splitting.

🤖 Generated with Claude Code