perf(server): streamed events no longer rewrite the whole thread row

[Baker-Harrison]

Problem

ProjectionStoreV2.apply ends with a step that runs for every event that is not a thread.* event. It selects the thread's projection row, schema-decodes the payload, sets updatedAt, schema-encodes it and writes the whole row back. Run, node, provider-turn and turn-item events all take that path, so a streamed turn pays a full decode and encode of the thread row for every flushed update, only to move one timestamp.

Change

The timestamp is patched in place with one statement:

UPDATE orchestration_v2_projection_threads
SET updated_at = ?, payload_json = json_set(payload_json, '$.updatedAt', ?)
WHERE thread_id = ?

The value is encoded with the thread schema's own updatedAt codec, so what is stored is the same string as before. This is the idiom run.background-work-cancelled already uses to patch a single run field. thread.* events still write the full row.

One side effect goes away: the old round trip also rewrote an older-shaped payload into the current encoded shape whenever any event touched the thread. That now happens only on thread.* events. Readers decode through the same schema either way, and the SQL that reads thread payload fields directly (archivedAt, settledOverride, snoozedUntil, pullRequests, and so on) uses IS NULL or json_array_length(...) > 0 checks that treat an absent field like a null or empty one.

Scope and approval

There is no linked issue or discussion. I am submitting this as a focused performance change with no intended change to behavior: the thread's updatedAt and the rest of its payload read back the same as before. If you would rather see an issue first, I will open one.

Verification

New test, dates thread activity by a run event and leaves the rest of the thread alone, in ProjectionStore.test.ts. It applies thread.created and then a run.created five seconds later, and asserts that:

• the thread reads back equal to the created thread with only updatedAt moved to the run event's time,
• the shell row carries the same updatedAt,
• applying the run event issued no SELECT against orchestration_v2_projection_threads.

It fails on main (expected [ Array(1) ] to be empty) and passes on this branch.

Also run, in apps/server:

• vp test run src/orchestration-v2/ProjectionStore.test.ts: 35 passed.
• vp test run src/orchestration-v2/runtimeLayer.test.ts src/orchestration-v2/ThreadManagementService.test.ts: 109 passed.
• vp run typecheck: passes. vp lint on the changed files: no errors.

Timing, from a scratch test that is not part of this PR: applying 5,000 turn-item.updated events to one thread through the test SQLite layer, three rounds each.

	Round 1	Round 2	Round 3
main at e24ea1d	553 ms	487 ms	479 ms
This branch	365 ms	324 ms	307 ms

That is about a third less time per applied event in this setup. It is one run on one machine, so read it as a direction, not a benchmark.

Not checked: a real on-disk database, or a running server during a live turn.

Environment: macOS, Node 26.7.0 (the repo asks for ^24.13.1; the install warned and everything ran).

Model and harness: Claude Opus 5.5 in Claude Code.

🤖 Generated with Claude Code

[macroscopeapp]

Approvability

Verdict: Approved at f544d9a

Macroscope's review found this PR approvable — This is a localized server performance change that preserves thread activity timestamps while avoiding full payload rewrites during streaming. The accompanying test verifies unchanged thread data, shell consistency, and the reduced SQL access pattern.

Notes:

• Diff unchanged. Approvability was decided on eligibility alone.

^{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

• Configuration used: Path: .coderabbit.config.ts
• Review profile: CHILL
• Plan: Advanced
• Run ID: 65a157dc-f170-428e-bc0c-d16c9dddba5d

📥 Commits

Reviewing files that changed from the base of the PR and between dc19285 and f544d9a.

📒 Files selected for processing (2)

• apps/server/src/orchestration-v2/ProjectionStore.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; 8 remain after this review.

📝 Walkthrough

ProjectionStoreV2 now updates a thread’s updatedAt timestamp directly in SQL when applying relevant events. A projection test checks the updated timestamp, unchanged thread fields, shell snapshot, and absence of a thread-table read.

Changes: Thread timestamp projection

Layer / File(s)	Summary
SQL timestamp patch and projection test apps/server/src/orchestration-v2/ProjectionStore.ts, apps/server/src/orchestration-v2/ProjectionStore.test.ts	The store encodes the event timestamp and patches updated_at and payload_json.updatedAt without reading and re-encoding the thread payload. The test checks that only updatedAt changes and that the shell snapshot reflects it, with no thread-table read.

Priority: ⬇️ Low

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

Change: Refactor

Suggested reviewers: t3dotgg

Merge Risk: ⚪ Minimal · up to f544d

The timestamp update appears to preserve thread projection behavior while avoiding a thread-row read. No actionable merge-blocking risk remains after normal checks.

### Architecture Summary

Architecture risk: 🔵 Low · up to f544d

The change affects 1 system.

Changed systems: apps/server

Architecture concerns
No architecture-level concerns identified.

Review details

Systems and components

• observed — apps/server (service) was modified; 2 changed files map to changed impact.

Before / after behavior

• observed — Modified behavior in apps/server/src/orchestration-v2/ProjectionStore.test.ts: Added a projection test that creates a thread with existing metadata, applies a run event timestamped five seconds later, and checks that only updatedAt changes in the thread projection and shell. It also asserts that applying the event performs no thread-table read.
• observed — Modified behavior in apps/server/src/orchestration-v2/ProjectionStore.ts: Adds an encoder for updatedAt using the thread schema field, for the SQL timestamp patch.
• observed — Modified behavior in apps/server/src/orchestration-v2/ProjectionStore.ts: For events that reach the generic activity-timestamp update, replaces reading, decoding, and re-encoding the thread payload with an in-place SQL update to updated_at and payload_json.updatedAt, using the encoded event timestamp.

Pre-merge checks · 4

Passed checks (4 passed)

Check name	Status	Explanation
Title check		The title clearly and concisely describes the main performance change: streamed events no longer rewrite the entire thread row.
Description check		The description includes all required sections. It explains the problem, implementation, scope rationale, focused verification, observed results, limitations, environment, and agent details.
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.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create a new PR

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

_{Comment @coderabbitai help to get the list of available commands.}

[AdEx-Partners-DE]

Numbers from a busy install, to put a size on what this saves. We adopted the change into a fork today (Windows 11); the figures are read-only queries on that server's statev2.sqlite, taken before the change went live.

threads	695
thread row payload_json, median / p90 / max	1,048 B / 1,352 B / 49,851 B
events in the last 24 hours	115,114, of which 111,855 are not thread.*
busiest three threads in those 24 hours	20,252, 15,775 and 11,696 such events, with thread rows of 40,921 B, 35,371 B and 49,851 B

So the typical row is small, but the threads that produce most events are the ones with the largest rows. Multiplying each thread's non-thread.* event count by its current row size gives about 2.65 GB of thread-row payload decoded, encoded and written back in one day under the old path. That is an estimate from today's row sizes, not a measurement of bytes written.

On our branch ProjectionStore.test.ts goes from 34 to 35 passing, runtimeLayer, FoundationPersistence and our queue tests still pass (130), and tsc --noEmit in apps/server is clean.

Not measured yet: the effect on write time or event-loop delay after the change. This server logs event loop stalls of 2 to 7 seconds a few times an hour; I will look at whether that changes once it runs this build, and say so here only if there is a clear difference.

Posted by Claude (Opus 5.5, Claude Code via T3 Code) on behalf of @AdEx-Partners-DE.

Dismissing prior approval to re-evaluate f544d9a