[Yash-Singh1]

Problem

Startup PR backfill used the full shell snapshot, which also reads message activity and historical item counts for every active thread. On a populated database, that work kept the reader busy and delayed other reads.

Change

Add a PR-specific snapshot that reads only thread metadata and the event sequence in one transaction. The PR service uses it for both backfill and per-thread refresh, while keeping the existing sync guards and backfill behavior.

With 6,873 synthetic threads and 7.04 million historical items, median PR initialization fell from 1,168 ms to 111 ms. Both versions dispatched 6,873 sync commands, made 64 branch lookups, and produced matching metadata and sequences.

Scope and approval

This is a focused performance fix. PR backfill needs active thread metadata, but the shell snapshot also loads history that PR discovery does not use.

Verification

Focused projection and PR service tests passed. check:changed passed, including 80 tests. A concurrent-write check confirmed that thread metadata and sequence came from the same snapshot.

Measurements used the installed Electron runtime with synthetic data. They measure PR snapshot reads and service initialization, not full desktop startup or network and dispatch costs. The fixture had less history than production.

Model: GPT-6 Codex.

[coderabbitai]

No actionable comments were generated in the recent review.

Walkthrough

The pull-request service now obtains thread metadata and the maximum thread-event sequence through a projection-store snapshot API. The API supports global and thread-targeted reads, with filters for archived and settled threads.

Changes: Pull-request snapshot flow

Layer / File(s)	Summary
Projection-store snapshot apps/server/src/orchestration-v2/ProjectionStore.ts, apps/server/src/orchestration-v2/ProjectionStore.test.ts	The store adds a snapshot query that reads selected thread data and the maximum event sequence in one transaction. It applies thread and unsettled filters, and tests check query scope, transaction grouping, and returned metadata.
Orchestrator and service integration apps/server/src/orchestration-v2/Orchestrator.ts, apps/server/src/orchestration-v2/ThreadPullRequestService.ts, apps/server/src/orchestration-v2/ThreadPullRequestService.test.ts, apps/server/src/orchestration-v2/ProviderTurnControlService.test.ts	The orchestrator exposes the snapshot query, and the pull-request service uses it for global and thread-targeted reads. Tests cover snapshot filtering and the sequence guard in the sync command.

Estimated code review effort: 3 (Moderate) | ~20 minutes

Change: Refactor

Sequence Diagram(s)

sequenceDiagram
  participant ThreadPullRequestService
  participant OrchestratorV2
  participant ProjectionStoreV2
  participant ReadOnlySQLiteClient
  ThreadPullRequestService->>OrchestratorV2: Request pull-request snapshot
  OrchestratorV2->>ProjectionStoreV2: Delegate snapshot options
  ProjectionStoreV2->>ReadOnlySQLiteClient: Read selected threads and event sequence in one transaction
  ReadOnlySQLiteClient-->>ProjectionStoreV2: Return rows and sequence
  ProjectionStoreV2-->>OrchestratorV2: Return decoded snapshot
  OrchestratorV2-->>ThreadPullRequestService: Return snapshot and sequence

Loading

Possibly related issues

• PR discovery rebuilds thread shells and counts unused history #18618: The issue describes full-shell reads for PR discovery; this change uses a filtered metadata snapshot and sequence read.
• History-wide reads saturate the single SQLite reader on large databases (thread switches take 12-50 s) #24895: The issue identifies a slow ThreadPullRequestServiceV2.synchronize shell read; this change replaces the PR-service read with a metadata snapshot.

Possibly related PRs

• pingdotgg/t3code#25728: Adds a related PR-sync snapshot read path that this change extends with a PR-specific API and filters.
• pingdotgg/t3code#25443: Moves PR discovery to thread metadata; this change implements a snapshot API with sequence and thread filters.
• pingdotgg/t3code#13691: Replaces full thread-list reads with targeted snapshot reads for per-thread pull-request checks.

Suggested reviewers: juliusmarminge, macroscopeapp

Merge Risk: Minimal · up to 98818

No actionable issue is established from the supplied evidence; the change is mergeable after normal checks.

Pre-merge checks: 4

Check name	Status	Explanation
Title check		The title "perf(server): read pull request metadata from a lightweight snapshot" matches the main change. The PR adds a PR-specific snapshot (getPullRequestSnapshot) that reads only thread metadata an…
Description check		The description follows the template's main sections: Problem, Change, Scope and approval, and Verification. The Problem section explains the slow startup backfill. The Change section describes the ne…
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): read pull request metadata from a lightweight snapshot" matches the main change. The PR adds a PR-specific snapshot (getPullRequestSnapshot) that reads only thread metadata and event sequence, and the PR service uses it for backfill and per-thread refresh. It uses a conventional commit prefix and plain language.

Full details: Description check

Explanation

The description follows the template's main sections: Problem, Change, Scope and approval, and Verification. The Problem section explains the slow startup backfill. The Change section describes the new snapshot and the service updates. The Verification section reports benchmark numbers (1,168 ms to 111 ms), sync command and branch lookup parity, focused test results, and the limits of the measurements. The Scope section explains why this is a focused performance fix. Two gaps remain: it does not link a triaged issue or maintainer approval, and the template asks for approval of direction and scope for changes like this. It also does not clearly state the reason for the performance fix's qualification under the approval rule beyond stating it is focused. The model line (GPT-6 Codex) is present as the template requests.

Resolution

Consider linking the triaged issue or maintainer discussion that approves this performance direction. If none exists, state why this small, focused performance fix qualifies without prior approval.

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/lightweight-pr-startup-snapshot
• File: .coderabbit.config.ts
• Commit: 988187f
• Layers: Repository TS config
• Review profile: CHILL
• Plan: Team
• Run ID: eca5da34-1df8-4225-99ca-bad8b6d8ee55

Commits

Reviewing files that changed from the base of the PR and between 260297b and 988187f.

Files selected for processing: 6

• apps/server/src/orchestration-v2/Orchestrator.ts
• apps/server/src/orchestration-v2/ProjectionStore.test.ts
• apps/server/src/orchestration-v2/ProjectionStore.ts
• apps/server/src/orchestration-v2/ProviderTurnControlService.test.ts
• apps/server/src/orchestration-v2/ThreadPullRequestService.test.ts
• apps/server/src/orchestration-v2/ThreadPullRequestService.ts

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

[macroscopeapp]

Approvability

Verdict: Approved at 988187f

Macroscope's review found this PR approvable — Pull-request discovery now reads a lightweight metadata snapshot instead of full thread shells. The read-only transactional path retains existing update safeguards without changing product defaults or external operations.

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: 988187f · 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.