A send or queued start to a long thread still reads 6–15 s of its history on main (follow-up to #29468) #36127

#29521 closed #29468, and #36100 narrowed the deferred-steer and cancel reads. On our two coordinator threads, a send and a queued start still read most of the thread's history on main at a044f0c0b3.

Setup: a block clone of our 49 GB statev2.sqlite, read through the real ProjectionStore (reader worker, node:sqlite), read-only, two passes. Thread A has 7,352 runs and thread B 6,886. Our local build was measured on the same clone earlier.

Where the time goes on thread A, second pass:

• Before a send, 6.4 s:
  • finding the last compaction, 1.2 s;
  • provider turns, 1.2 s;
  • runs, 1.1 s;
  • root nodes, subagents, provider threads, and user and error items, 0.7 s each.
• Before a queued start, 11.0 s:
  • user messages, 3.0 s;
  • nodes, 2.4 s;
  • runs, attempts and provider turns, 1.0–1.1 s each;
  • turn items, 0.7 s;
  • subagents, 0.6 s.

So one t3_thread_send to thread A spends about 11 s in reads, and the send read holds the thread's dispatch lock. A queued start holds the lock for its 11–15 s read before its turn start, which #35723 narrows, even begins.

Our build stages these reads; the #29468 comment describes how, with a link to the code. In short:

• One read transaction loads the thread and its runs, and only the active subagents, sessions, provider threads, requests, scopes and transfers.
• Messages, nodes, attempts, provider turns and items are then read by key, for the runs a send can steer, queue behind or restart.
• The preflight reads only running runs and their running turns.

What remains there is mostly the full runs read, about 1.1 s.

Measured and written by Claude (Opus 5.5) in T3 Code; posted with the owner's approval.