fix(server): shell reads no longer scan every runless item per failed thread - #14181
Conversation
… thread The failure lookups in the thread shell query matched turn items by node_id when the failed run had no root node. Imported history leaves tens of thousands of items with a null node_id, so SQLite walked all of them once per thread and blocked startup for minutes. Pin both lookups to the thread and run index. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
ApprovabilityVerdict: Approved at Macroscope's review found this PR approvable — This is a narrowly scoped server bug fix that keeps shell failure results unchanged while constraining both lookups to the current thread and an existing index, preventing expensive scans of unrelated runless history. A targeted regression test verifies both query plans, and no defaults, schemas, capabilities, or sensitive areas are changed. You can add or adjust custom eligibility rules. Learn more. |
Thread transfer impact✅ Thread transfer remains within every enforced ceiling.
Baseline: unavailable · PR result: Scenario and decoded snapshot size10 historical turns, 5 command tools per turn, 878.9 KiB retained MCP result per historical turn, and a 1.05 MiB retained result in the measured turn.
Updated in place by a trusted workflow. PR artifacts are strictly validated and never executed. |
977bf4a
into
t3code/codex-turn-mapping
The V2 preview froze on startup for minutes at 100% CPU: the server never answered, so the app showed no providers. #13877 added a per-thread lookup of the failed run's error item to the thread shell query. When that run has no root node, SQLite matched items by `node_id IS NULL` through the node index. Imported history leaves tens of thousands of items with a null `node_id`, so the query walked all of them once for every failed thread. A real database (1,918 threads, 304k turn items) spent 91 of 92 profiled seconds inside this synchronous query.
Both failure lookups now use the thread and run index.
🤖 Generated with Claude Code