perf(server): visiting a thread no longer copies the whole thread into the event log#31849

Problem

thread.visited carries the whole thread as its payload, so every visit writes a full copy of the thread into the event log and sends it to every client subscribed to that thread. A visit only changes lastVisitedAt, plus opens when the user opened the thread. The existing comment in dispatchThreadVisit already says a read receipt shouldn't scale with the thread's history. The payload still does, though, mostly through pullRequests.

On my server, one long-lived thread is linked to 847 pull requests, so its thread payload is 866 KB, 99.9% of it pull-request links. Its event log holds 2,557 thread.visited events from Nov 5 alone, 2,048 MB in total: about 0.8 MB written per visit. Compaction later deletes them, but each one has already been written, sent to subscribed clients and re-decoded.

This is the same duplication #19248 removed from pull-request sync events.

Change

Visits now emit a new thread.visit-recorded event whose payload is only the read state, { lastVisitedAt, opens? }. It is applied the way #19248 applies thread.pull-request-link-updated:

• The SQL projection reads the thread, applies the visit, and writes it through the existing thread.visited path, which still leaves updatedAt alone.
• applyToProjection and the client projection merge the read state into the thread they already hold.
• A small applyOrchestrationV2ThreadVisit helper in contracts keeps the server and clients identical.
• The agent-awareness relay treats it like thread.visited.

Existing thread.visited events still decode and replay. Older clients skip unknown event types (OrchestrationV2UnknownThreadStreamEvent) and still get lastVisitedAt from the shell. There's no schema migration.

Scope and approval

This is a focused persistence fix for an obvious duplication: one visit copied every linked pull request into the event log. It follows the slim-event approach maintainers took in #19248. Visit behavior doesn't change: the stale-visit watermark, opens ranking and updatedAt handling all stay the same. Only the event payload becomes visit-specific.

Verification

• runtimeLayer.test.ts, in two existing cases:

  • "carries the visited watermark through the V2 shell projection" now also asserts that the visit's stored event is thread.visit-recorded with payload { lastVisitedAt }.
  • "counts opens on the server clock…" asserts that an opened visit stores only lastVisitedAt and opens, and that a projection rebuild from the event log keeps the same opens.
  • On main, both fail: the stored event is thread.visited with the full thread.

• orchestrationV2Projection.test.ts: a new case shows the client projection merges the read state, keeps opens unless the visit was an open, and doesn't bump updatedAt.

• From apps/server: vp test run src/orchestration-v2/runtimeLayer.test.ts src/orchestration-v2/ProjectionStore.test.ts src/orchestration-v2/FoundationPersistence.test.ts src/relay/AgentAwarenessRelay.test.ts gives 239/239 passing. From packages/client-runtime: vp test run src/state/orchestrationV2Projection.test.ts gives 17/17. vp run check:changed passed: format, lint, knip, typecheck (36 packages), and 9 test files with 233 tests.

• Runtime numbers from my server's database, opened read-only:

  Per visit to that thread	Before	After
  Event payload written and sent	~866 KB	44 bytes (a few hundred bytes for an open)
  Encoding the event payload (Node 26 benchmark of that thread's real payload)	~12 ms	negligible

Not checked:

• The projection row is still rewritten on each visit, so a visit still reads and writes the thread row once. This change removes only the event copy and the client fan-out.
• I didn't measure inside a server build.

Model: Claude Opus 5.5, harness: Claude Code

🤖 Generated with Claude Code