[only21mil]

Problem

Sending a message to a settled thread, a snoozed thread, or a thread's first message with a title seed made dispatchMessage reread the whole command projection from SQLite after each of those steps. Each reread loads 12 projection collections plus the thread row and refolds every pending event while holding the thread's dispatch lock. A message that wakes a settled, snoozed thread and seeds its title paid for three of them.

Measured on synthetic data with an in-memory database (one message.dispatch, defer_start, Codex stub adapter, effect worker off):

Case	SELECTs before	SELECTs after
Thread not settled	25	25
Settled	38	25
Settled + snoozed + title seed	71	26
Settled, 300 completed runs	40	26

On the 300-run thread, the median settled dispatch went from about 33 ms to about 20 ms (two runs of 9 and 15 samples after a dropped warmup: 33.45 / 32.46 ms before, 19.81 / 20.40 ms after).

Change

In the three branches (thread.unsettled, thread.unsnoozed, and the title-seed thread.metadata-updated), keep the event emit returns and apply it to the projection already in hand with applyToProjection, as the lastVisitedAt branch just above already does. No other code changes.

Why behavior is unchanged: projection starts as getProjectionWithPendingEvents for this thread, and emit only appends the returned event to the pending list. Nothing between that first read and the old rereads writes this thread's rows (the dispatch runs under the thread lock, and the only store calls in between are reads such as getMessageCount). So the reread folded the same stored rows and the same pending events plus the one new event. applyToProjection treats all three event types as a plain thread: event.payload replace, which is exactly that last fold step. The reread's thread.created special case only matters for a pending thread.created, which the initial projection already includes.

Scope and approval

No prior issue or discussion. This is a small, focused performance fix inside one function with no change to product behavior, which CONTRIBUTING.md lists among the changes most likely to be accepted. Maintainers, please confirm the scope: it touches only these three rereads and leaves getProjectionWithPendingEvents and its other callers alone.

Verification

• vp test run apps/server/src/orchestration-v2/Orchestrator.control-reads.test.ts apps/server/src/orchestration-v2/ThreadSettlementService.test.ts apps/server/src/orchestration-v2/runtimeLayer.test.ts apps/server/src/orchestration-v2/ThreadTitleRegenerationService.test.ts apps/server/src/orchestration-v2/ThreadLaunchService.test.ts apps/server/src/orchestration-v2/ThreadMessageIntake.test.ts: 6 files, 207 tests passed.
• No existing case crossed more than one of these branches in a single dispatch, so I extended the snooze-wake case in runtimeLayer.test.ts ("carries snooze, settle and title state through the V2 shell projection"). It now settles and snoozes the thread, then dispatches with a title seed, and asserts the thread ends unsnoozed, unsettled, retitled and with the title-regeneration marker. Dropping the unsnooze fold as a mutation check makes it fail (expected DateTime.Utc(2099-07-25T09:00:00.000Z) to equal null); with the fold, it passes.
• vp run check:changed 15fe283272: format, lint, knip, typecheck (3 packages) and tests (4 files, 122 tests) all pass.
• SELECT counts and timings above came from a temporary harness built like Orchestrator.control-reads.test.ts. It wraps node:sqlite StatementSync.prototype.all and counts SELECT/WITH statements during the one dispatch. The harness is not part of this PR.
• No UI change: this only removes server-side reads, and the resulting thread state is identical, so no screen shows anything different.

Not checked:

• Timing on a file-backed database or with real user data; the numbers are from an in-memory database on one machine.
• No read-count assertion was added; the repo's testing rules treat that as a mock-call mirror.

Prior PRs

None found. Searches for getProjectionWithPendingEvents and dispatch-projection perf work turned up no open or closed PR making this change.

Generated with Claude Opus 5.5 in T3 Code Nightly

[macroscopeapp]

Approvability

Verdict: Approved at 91d7cfa

Macroscope's review found this PR approvable — Message dispatch now applies three emitted thread updates to its existing projection instead of rereading the database. Event payloads and persistence remain unchanged, making this a narrowly scoped performance optimization with no evident material exposure.

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

[coderabbitai]

No actionable comments were generated in the recent review.

Recent review info

Run configuration

• Source mode: Auto
• Repository: pingdotgg/t3code
• Branch: main
• File: .coderabbit.config.ts
• Commit: 15fe283
• Layers: Repository TS config
• Review profile: CHILL
• Plan: Advanced
• Run ID: 964f3ba7-2f2a-40fb-947f-e36ffd86b9cf

Commits

Reviewing files that changed from the base of the PR and between 15fe283 and 91d7cfa.

Files selected for processing: 2

• apps/server/src/orchestration-v2/Orchestrator.ts
• apps/server/src/orchestration-v2/runtimeLayer.test.ts

Limit details: You’ve used all 10 included reviews currently available.

Walkthrough

dispatchMessage now applies emitted thread events to its local projection instead of reloading pending events. The runtime test adds checks for settle and title state after wake.

Changes: Thread projection updates

Layer / File(s)	Summary
Apply events and verify wake state apps/server/src/orchestration-v2/Orchestrator.ts, apps/server/src/orchestration-v2/runtimeLayer.test.ts	dispatchMessage applies unsettled, unsnoozed, and title-regeneration events to the local projection. The test checks cleared settle fields, the seeded title, and the title-regeneration request ID after wake.

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

Possibly related issues

• pingdotgg/t3code#24660: This change removes repeated projection reloads in dispatchMessage, which may reduce the read load described in the issue. It does not add reader concurrency or cache ensureTranscript results.

Suggested reviewers: juliusmarminge

Merge Risk: Minimal · up to 91d7c

No actionable merge-blocking risk remains; the optimization preserves wake-state behavior.

Pre-merge checks: 4

Check name	Status	Explanation
Title check		The title clearly identifies the performance improvement and the affected settle, snooze, and title-update paths.
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.
Description check		The description follows the repository template closely and covers all required sections. It states the problem with measured SELECT counts and timings, and it explains the change: three rereads are r…

Full details: Description check

Explanation

The description follows the repository template closely and covers all required sections. It states the problem with measured SELECT counts and timings, and it explains the change: three rereads are replaced with applyToProjection on the projection already in hand. It gives a reasoned argument that behavior is unchanged. The Scope and approval section explains why no prior issue exists and asks maintainers to confirm scope. Verification lists the test commands, the extended snooze-wake test, a mutation check, and what was not checked. The Problem and Change sections are short but adequate for a focused performance fix.

Finishing Touches

Generate unit tests (beta)

• Create a new PR

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

[maria-rcks]

Note

Written by gpt-6.1-sol on behalf of Maria

Verified in a real dev environment

re-verified unchanged head 91d7cfa6ece359afa228bfda412b5baf7a82f7b3 against github/main at 955e2bfbb5c092c54ad795c8d379fec99702a6b5 on this linux vm. used repository playwright with /usr/bin/google-chrome, the real dev web client, and codex gpt-6.1-sol through the local proxy. created the project and threads through the app. stopped main before starting the pr and copied only the app-created isolated baseline state. no mocks or demo data.

• settled and snoozed a thread through its menu, then sent a message. codex returned WAKE_PR_OK, the thread left snoozed, and persisted settledOverride, settledAt, snoozedUntil, and snoozedAt were null.
• sent a first message in a new thread. codex returned TITLE_OK and title generation completed.
• sent an ordinary follow-up. codex returned FOLLOWUP_OK. both replies and the generated title survived a browser reload.
• reproduced redundant projection loads on main with an external sqlite preload while driving real ui sends. main to pr: settle plus snooze 3 to 1, first-message title seed 2 to 1, ordinary follow-up 1 to 1. these count the characteristic command-projection query, not all sql statements or latency. no source instrumentation or provider stubs were used.
• vp run check:changed 15fe2832727893cbdd2214383f9f971474849695 passed through blacksmith: format, lint, knip, graphql, three package typechecks, and 122 tests in four files. pr ci has 31 successful checks, zero pending or failing. no fix or push was needed.

short runtime transcript

Not verified

native ios/android, the electron shell, other providers, remote/relay/tunnel connections, all three changed branches together in one dispatch, and large-history latency were not exercised. no latency claim is made. the recording's checkpoint diff reflects switching the project checkout from current main to the older exact pr head; this verification made no source edits. uploaded video playback and seeking were checked in chrome.