[Yash-Singh1]

Problem

Runtime recovery queried streaming messages by thread, so SQLite scanned message history even when no runs in that thread were eligible for recovery. Large histories made some recovery reads expensive.

Change

Start the streaming-message query from eligible runs and use the existing message run index. Keep the thread and streaming filters, deterministic message ordering, and sequential recovery behavior. Add a regression test for eligible and terminal run states, cross-thread rows, ordering, and empty run cohorts.

Scope and approval

This is a focused query-planning fix for an existing recovery path. It changes no schema or indexes and preserves which messages recovery returns.

Verification

The focused regression fixture and 29 recovery tests passed. check:changed passed, including formatting, lint, affected-package typechecks, and 66 tests. In a bounded native Electron SQLite benchmark with 2,624 messages, six empty-cohort query reads took 3.604 ms before and 0.065 ms after; projection reads took 6.652 ms before and 2.714 ms after. These synthetic measurements do not establish full startup savings or production disk and worker performance.

Model: Codex, harness: T3 Code

[coderabbitai]

No actionable comments were generated in the recent review.

Walkthrough

Runtime recovery now retrieves streaming messages by joining eligible runs to messages through the run index. A new test checks the selected messages, their ordering, and the query index.

Changes: Streaming recovery

Layer / File(s)	Summary
Run-indexed streaming recovery apps/server/src/orchestration-v2/ProjectionStore.ts, apps/server/src/orchestration-v2/ProjectionRecovery.test.ts	Recovery uses a cross join from eligible runs to messages and retains the thread, streaming-message, and run-status filters. The test checks filtering, ordering, empty candidate sets, and use of the run index.

Estimated code review effort: 2 (Simple) | ~10 minutes

Change: Refactor

Possibly related issues

• Issue 24895 describes costly recovery reads on thread switches. This change updates one query identified in the issue; other statements and the reader-permit concern remain outside this change.

Suggested reviewers: t3dotgg, macroscopeapp

Merge Risk: Minimal · up to 0c9ee

No actionable merge-blocking risk is established by the available evidence.

Pre-merge checks: 4

Check name	Status	Explanation
Title check		The title "perf(server): bound streaming recovery reads by active runs" matches the main change. The raw summary and objectives say the streaming-message recovery query now starts from active or eligi…
Description check		The description follows the template sections. It has a Problem section that explains the thread-scoped scan of message history when no runs are eligible. The Change section describes the run-driven q…
Linked Issues check		Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check		Check skipped because no linked issues were found for this pull request.

Full details: Title check

Explanation

The title "perf(server): bound streaming recovery reads by active runs" matches the main change. The raw summary and objectives say the streaming-message recovery query now starts from active or eligible runs and uses the message run index, instead of scanning messages by thread. The title is concise, follows the conventional commit format, and names the performance aspect and the scope of the change.

Full details: Description check

Explanation

The description follows the template sections. It has a Problem section that explains the thread-scoped scan of message history when no runs are eligible. The Change section describes the run-driven query, the existing message run index, and the regression test. The Scope and approval section explains that this is a focused query-planning fix with no schema or index changes, but it does not link a triaged issue or maintainer approval, which the template asks for. The Verification section lists focused test results and benchmark numbers and states what the measurements do not establish. The model and harness line is present. The missing issue or approval link is the main gap.

Resolution

Add a link to the triaged bug issue or the discussion with explicit maintainer approval, including the approval comment. Alternatively, explain why this very small, focused fix of an obvious bug qualifies without a prior issue or discussion.

Finishing Touches

Generate docstrings

• Commit to this branch
• Create a new PR

Generate unit tests (beta)

• Commit to this branch
• Create a new PR

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

CodeRabbit Verify

• Run CodeRabbit Verify to test the changes in this pull request.

Recent review info

Run configuration

• Source mode: Auto
• Repository: pingdotgg/t3code
• Branch: t3/narrow-streaming-message-recovery
• File: .coderabbit.config.ts
• Commit: 0c9eec6
• Layers: Repository TS config
• Review profile: CHILL
• Plan: Team
• Run ID: bc51a555-de60-474d-8191-517c201460fe

Commits

Reviewing files that changed from the base of the PR and between 260297b and 0c9eec6.

Files selected for processing: 2

• apps/server/src/orchestration-v2/ProjectionRecovery.test.ts
• apps/server/src/orchestration-v2/ProjectionStore.ts

Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 7 remain after this review.

[macroscopeapp]

Approvability

Verdict: Approved at 0c9eec6

Macroscope's review found this PR approvable — Streaming recovery reads now start from eligible runs and use an existing index instead of scanning thread message history. The change preserves filtering and ordering without changing stored data, schema, or product defaults.

Notes:

• Diff unchanged. Approvability was decided on eligibility alone.

^{You can add or adjust custom eligibility rules. Learn more.}

[github-actions]

Thread transfer impact

✅ Thread transfer remains within every enforced ceiling.

Provider	Metric	Main baseline	This PR	Impact	PR ceiling
Codex	Total thread wire	5.0 KiB	5.0 KiB	−19 B (−0.4%)	6.8 KiB	✅
Codex	Thread snapshot wire	3.8 KiB	3.8 KiB	0 B (0.0%)	4.9 KiB	✅
Codex	Live turn WebSocket wire	1.3 KiB	1.2 KiB	−19 B (−1.5%)	2.0 KiB	✅
Codex	Live turn WebSocket decoded	21.6 KiB	21.6 KiB	0 B (0.0%)	24.4 KiB	✅
Codex	Live turn messages	2	2	0 (0.0%)	8	✅
Claude	Total thread wire	5.0 KiB	5.0 KiB	0 B (0.0%)	6.8 KiB	✅
Claude	Thread snapshot wire	3.8 KiB	3.8 KiB	0 B (0.0%)	4.9 KiB	✅
Claude	Live turn WebSocket wire	1.2 KiB	1.2 KiB	0 B (0.0%)	2.0 KiB	✅
Claude	Live turn WebSocket decoded	21.9 KiB	21.9 KiB	0 B (0.0%)	24.4 KiB	✅
Claude	Live turn messages	2	2	0 (0.0%)	8	✅

Baseline: 260297b · PR result: 0c9eec6 · Source CI: success

Scenario and decoded snapshot size

10 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.

• Codex decoded thread snapshot: 108.5 KiB
• Claude decoded thread snapshot: 108.8 KiB

Updated in place by a trusted workflow. PR artifacts are strictly validated and never executed.