Thread list snapshot is 17 MB (1.8 MB gzipped), and 62% of it is pull request link bodies

[bompus]

What happened

GET /api/orchestration/shell (ProjectionStoreV2.getShellSnapshot) puts every pull request link on every thread shell. Each link carries its full snapshot (title, branches, author with avatar URL, line counts, checks, merge state) and its stack. On a real database (1,404 active and 207 archived threads, 17,359 links, 159 links on the busiest thread) the snapshot is 17.0 MB of JSON, 1.78 MB gzipped. With snapshot and stack dropped from each link it is 6.5 MB, 0.33 MB gzipped. #16713 found the same ratio on another database (9.5 of 11.7 MB).

Diagnosis

threadShellFromProjection and shellFromState copy threadPullRequestsOf(thread) into the shell unchanged (apps/server/src/orchestration-v2/ProjectionStore.ts:1473 and :1741), and OrchestrationV2ThreadShell declares the full ThreadPullRequestLink array (packages/contracts/src/orchestrationV2.ts:1940).

Server cost per snapshot read, measured by calling getShellSnapshot through a read-only connection to a live database (median of 7 repetitions, two runs, warm page cache):

Stage	Run 1	Run 2
SQL reads	126.9 ms	123.8 ms
Schema decode	130.9 ms	122.3 ms
Schema encode	104.5 ms	102.7 ms
JSON.stringify	46.8 ms	48.3 ms

That is about 0.4 s of main-thread work. Decoding and encoding the links alone, in isolation (16,210 links on the active threads), takes 35 ms and 33 ms, so about a quarter to a third of the decode and encode stages.

Wire and client cost for the same snapshot:

	Full	Links without snapshot and stack	Benefit
JSON size	17.02 MB	6.51 MB	62% smaller
Gzipped size	1.776 MB	0.328 MB	82% smaller (5.4 times)
Gzip time	78 to 81 ms	19 ms	76% faster
JSON.parse	22.7 to 23.1 ms	7.4 to 7.8 ms	67% faster

The client already decodes the links after the rows (decodeShellSnapshotDeferringPullRequests, #16713), so its remaining cost is bandwidth and parse. The server still reads, decodes, encodes and compresses every body on every client connect, and for each background pass that reads the shell.

Not measured: the server stages for the slimmer payload (only parse and gzip were), a real network, or a device. Repeat-run spread was about 7%. Byte sizes are exact.

Steps to reproduce

1. Use a database where agents or users have linked many pull requests to threads.
2. Call ProjectionStoreV2.getShellSnapshot({}) and time it, then encode the result with Schema.toCodecJson(OrchestrationV2ThreadShellSnapshot) and measure the JSON and gzip size.
3. Repeat after removing snapshot and stack from each link to see the size the shell would have without the bodies.

I have a small harness that does this and can share it.

Version

upstream/main at dc19285 (2026-10-13)

Environment

Linux (WSL2), Node 24, 16 vCPU. One database, 16.5 GB, 1,404 active V2 threads.

Evidence

threads 1404, archived 207, links 17359
full             17,022,665 bytes json, 1,775,769 gzip
links w/o bodies  6,509,264 bytes json,   328,475 gzip
sql 126.9 ms  decode 130.9 ms  encode 104.5 ms  stringify 46.8 ms  (run 1, median of 7)

Related issues

#14703 (read moves to a worker, payload unchanged), #16713 (client defers link decode), #16558 (PR sync event stores whole thread), #18559 (compaction never runs). This one is the shell payload sent to clients.

Fix applied or workaround

None. Would you take a shell that carries a compact link (key, URL, state), with the bodies fetched when the pull request panel opens or a row is on screen? It changes the shell contract for web, mobile and desktop, so I would like your direction before writing it. I have not written the change.

Filed by

Claude Sonnet 5.5, in Claude Code

[bompus]

I can open a pull request for this once triage confirms the direction. I have not written it yet. One option is to keep each link's identifying fields in the thread shell and load its snapshot and stack only for the thread being opened. That changes the shell contract, so I would like your view on the direction before writing it, and I would measure server time, JSON size and gzip size before and after.