fix(server): bound thread shell-summary reads

[t3-code]

what changed

• normalize user-input request ids and state transitions when projecting activities
• maintain a one-row pending-input summary per thread through indexed old/new request lookups
• read latest user-message timestamps through a partial covering index
• repair old and new thread owners after destructive activity-id and message-id upserts
• reconcile existing shell rows in migration 42 and self-heal a missing lifecycle summary on replay

why

fixes#5719.

common assistant messages and routine activities previously rebuilt thread shell fields by loading and decoding full message and activity history. the first fix replaced that with a scalar aggregate, but review found the aggregate still scanned and decoded every lifecycle row.

this revision moves normal runtime work to indexed point lookups plus one summary row. migration 42 safely upgrades databases that already recorded migration 41, ignores malformed json and non-string failure details, and repairs stale shell fields. live updates, owner-changing upserts, cursor replay, and revert reconstruction now use the same sqlite ordering and normalized state.

testing

• vp test run apps/server/src/orchestration apps/server/src/persistence (302 passed)
• vp run --filter t3 typecheck
• vp check <changed server files>
• git diff --check

regressions cover 10,000 matching lifecycle rows with large payloads, malformed lifecycle json, non-string failure details, activity-id and message-id replacement within and across threads, missing-summary replay, equal timestamps, stale/unknown response failures, migration 41-to-42 upgrades, shell-row reconciliation, and exact production query plans.

checklist

• i have performed a self-review of my changes
• i have added tests that prove my fix is effective
• new and existing tests pass locally

---

Note

Medium Risk
Touches projection correctness for thread list badges and pending-input counts across migrations, transactional upserts, and revert rebuild paths; wrong deltas would show stale UI state but is well-covered by tests.

Overview
Thread list shell summary fields (latest_user_message_at, pending_user_input_count, etc.) no longer rebuild by loading full message/activity history on every routine event.

Persistence: Activities now store normalized user_input_request_id / user_input_state and maintain a per-thread projection_thread_user_input_summaries row via transactional upserts (including cross-thread activity-id moves). Messages upsert refreshes latest_user_message_at on affected threads through an indexed “latest user message” query.

Projection pipeline: In-memory derivePendingUserInputCountFromActivities and the old refreshThreadShellSummary full-scan path are removed. Common events update shell fields incrementally; thread.reverted still calls rebuildThreadShellSummary, which uses scalar/count queries instead of hydrating payloads.

Migrations 41–42: Add lifecycle indexing, then upgrade to the summary table + covering indexes and backfill/reconcile existing projection_threads rows (including safe handling of malformed JSON).

^{Reviewed by Cursor Bugbot for commit 6dba7cc. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Bound thread shell-summary reads using pre-aggregated counts instead of full activity hydration

• Thread shell summary fields (pending_user_input_count, latest_user_message_at) are now maintained incrementally in projection_thread_user_input_summaries and directly on projection_threads, rather than being recomputed by scanning all activities/messages.
• Activity upserts and deletes in ProjectionThreadActivities.ts maintain per-thread pending counts via delta updates to the summary table, including correct handling of cross-thread activity moves.
• Message upserts and deletes in ProjectionThreadMessages.ts synchronize latest_user_message_at on projection_threads, including correcting the previous thread when a message moves.
• ProjectionPipeline.ts projection handlers now call targeted repository aggregates per event type; thread.reverted triggers a full rebuildThreadShellSummary using persisted aggregates.
• Migration 042 backfills user_input_request_id/user_input_state columns on activities, creates the summary table, and reconciles existing thread-level counts and timestamps.
• Risk: upserts for activities and messages now run in transactions with additional reads and writes, increasing per-event DB load.

^{Macroscope summarized 6dba7cc.}

[github-actions]

Thread transfer impact

✅ Thread transfer remains within every enforced ceiling.

ℹ️ The exact PR base did not have a successful artifact. Baseline uses the latest successful main measurement shown below.

Provider	Metric	Main baseline	This PR	Impact	PR ceiling
Codex	Total thread wire	11.3 KiB	12.4 KiB	+1.1 KiB (+9.9%)	15.1 KiB	✅
Codex	Thread snapshot wire	5.5 KiB	6.3 KiB	+837 B (+15.0%)	7.3 KiB	✅
Codex	Live turn WebSocket wire	5.9 KiB	6.2 KiB	+310 B (+5.2%)	7.8 KiB	✅
Codex	Live turn WebSocket decoded	49.7 KiB	52.4 KiB	+2.7 KiB (+5.3%)	66.4 KiB	✅
Codex	Live turn messages	16	10	−6 (−37.5%)	21	✅
Claude	Total thread wire	11.3 KiB	12.4 KiB	+1.1 KiB (+9.6%)	15.1 KiB	✅
Claude	Thread snapshot wire	5.5 KiB	6.3 KiB	+817 B (+14.6%)	7.3 KiB	✅
Claude	Live turn WebSocket wire	5.9 KiB	6.1 KiB	+301 B (+5.0%)	7.8 KiB	✅
Claude	Live turn WebSocket decoded	50.6 KiB	53.2 KiB	+2.7 KiB (+5.3%)	66.4 KiB	✅
Claude	Live turn messages	16	10	−6 (−37.5%)	21	✅

Baseline: 83d769f · PR result: 6dba7cc · 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: 99.9 KiB
• Claude decoded thread snapshot: 100.6 KiB

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

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — This PR introduces database schema changes (new columns, tables, indexes) and refactors shell summary tracking from in-memory full-collection scans to transactional incremental updates with delta tracking. The PR's own description labels it 'Medium Risk' affecting projection correctness, warranting human review.

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

[t3dotgg]

Note

🤖 GPT-5.6 Sol responding on behalf of Theo

Closing in favor of merged #8150, which removes repeated full-history reads from assistant messages and routine activities. The additional summary-state migration and lifecycle changes were not needed for that fix. Your work is credited in #8150.

[t3-code]

what changed

• normalize user-input request ids and state transitions when projecting activities
• maintain a one-row pending-input summary per thread through indexed old/new request lookups
• read latest user-message timestamps through a partial covering index
• repair old and new thread owners after destructive activity-id and message-id upserts
• reconcile existing shell rows in migration 42 and self-heal a missing lifecycle summary on replay

why

fixes#5719.

common assistant messages and routine activities previously rebuilt thread shell fields by loading and decoding full message and activity history. the first fix replaced that with a scalar aggregate, but review found the aggregate still scanned and decoded every lifecycle row.

this revision moves normal runtime work to indexed point lookups plus one summary row. migration 42 safely upgrades databases that already recorded migration 41, ignores malformed json and non-string failure details, and repairs stale shell fields. live updates, owner-changing upserts, cursor replay, and revert reconstruction now use the same sqlite ordering and normalized state.

testing

• vp test run apps/server/src/orchestration apps/server/src/persistence (302 passed)
• vp run --filter t3 typecheck
• vp check <changed server files>
• git diff --check

regressions cover 10,000 matching lifecycle rows with large payloads, malformed lifecycle json, non-string failure details, activity-id and message-id replacement within and across threads, missing-summary replay, equal timestamps, stale/unknown response failures, migration 41-to-42 upgrades, shell-row reconciliation, and exact production query plans.

checklist

• i have performed a self-review of my changes
• i have added tests that prove my fix is effective
• new and existing tests pass locally

---

Note

Medium Risk
Touches projection correctness for thread list badges and pending-input counts across migrations, transactional upserts, and revert rebuild paths; wrong deltas would show stale UI state but is well-covered by tests.

Overview
Thread list shell summary fields (latest_user_message_at, pending_user_input_count, etc.) no longer rebuild by loading full message/activity history on every routine event.

Persistence: Activities now store normalized user_input_request_id / user_input_state and maintain a per-thread projection_thread_user_input_summaries row via transactional upserts (including cross-thread activity-id moves). Messages upsert refreshes latest_user_message_at on affected threads through an indexed “latest user message” query.

Projection pipeline: In-memory derivePendingUserInputCountFromActivities and the old refreshThreadShellSummary full-scan path are removed. Common events update shell fields incrementally; thread.reverted still calls rebuildThreadShellSummary, which uses scalar/count queries instead of hydrating payloads.

Migrations 41–42: Add lifecycle indexing, then upgrade to the summary table + covering indexes and backfill/reconcile existing projection_threads rows (including safe handling of malformed JSON).

^{Reviewed by Cursor Bugbot for commit 6dba7cc. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Bound thread shell-summary reads using pre-aggregated counts instead of full activity hydration

• Thread shell summary fields (pending_user_input_count, latest_user_message_at) are now maintained incrementally in projection_thread_user_input_summaries and directly on projection_threads, rather than being recomputed by scanning all activities/messages.
• Activity upserts and deletes in ProjectionThreadActivities.ts maintain per-thread pending counts via delta updates to the summary table, including correct handling of cross-thread activity moves.
• Message upserts and deletes in ProjectionThreadMessages.ts synchronize latest_user_message_at on projection_threads, including correcting the previous thread when a message moves.
• ProjectionPipeline.ts projection handlers now call targeted repository aggregates per event type; thread.reverted triggers a full rebuildThreadShellSummary using persisted aggregates.
• Migration 042 backfills user_input_request_id/user_input_state columns on activities, creates the summary table, and reconciles existing thread-level counts and timestamps.
• Risk: upserts for activities and messages now run in transactions with additional reads and writes, increasing per-event DB load.

^{Macroscope summarized 6dba7cc.}

[github-actions]

Thread transfer impact

✅ Thread transfer remains within every enforced ceiling.

ℹ️ The exact PR base did not have a successful artifact. Baseline uses the latest successful main measurement shown below.

Provider	Metric	Main baseline	This PR	Impact	PR ceiling
Codex	Total thread wire	11.3 KiB	12.4 KiB	+1.1 KiB (+9.9%)	15.1 KiB	✅
Codex	Thread snapshot wire	5.5 KiB	6.3 KiB	+837 B (+15.0%)	7.3 KiB	✅
Codex	Live turn WebSocket wire	5.9 KiB	6.2 KiB	+310 B (+5.2%)	7.8 KiB	✅
Codex	Live turn WebSocket decoded	49.7 KiB	52.4 KiB	+2.7 KiB (+5.3%)	66.4 KiB	✅
Codex	Live turn messages	16	10	−6 (−37.5%)	21	✅
Claude	Total thread wire	11.3 KiB	12.4 KiB	+1.1 KiB (+9.6%)	15.1 KiB	✅
Claude	Thread snapshot wire	5.5 KiB	6.3 KiB	+817 B (+14.6%)	7.3 KiB	✅
Claude	Live turn WebSocket wire	5.9 KiB	6.1 KiB	+301 B (+5.0%)	7.8 KiB	✅
Claude	Live turn WebSocket decoded	50.6 KiB	53.2 KiB	+2.7 KiB (+5.3%)	66.4 KiB	✅
Claude	Live turn messages	16	10	−6 (−37.5%)	21	✅

Baseline: 83d769f · PR result: 6dba7cc · 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: 99.9 KiB
• Claude decoded thread snapshot: 100.6 KiB

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

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — This PR introduces database schema changes (new columns, tables, indexes) and refactors shell summary tracking from in-memory full-collection scans to transactional incremental updates with delta tracking. The PR's own description labels it 'Medium Risk' affecting projection correctness, warranting human review.

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

[t3dotgg]

Note

🤖 GPT-5.6 Sol responding on behalf of Theo

Closing in favor of merged #8150, which removes repeated full-history reads from assistant messages and routine activities. The additional summary-state migration and lifecycle changes were not needed for that fix. Your work is credited in #8150.

[t3-code]

what changed

• normalize user-input request ids and state transitions when projecting activities
• maintain a one-row pending-input summary per thread through indexed old/new request lookups
• read latest user-message timestamps through a partial covering index
• repair old and new thread owners after destructive activity-id and message-id upserts
• reconcile existing shell rows in migration 42 and self-heal a missing lifecycle summary on replay

why

fixes#5719.

common assistant messages and routine activities previously rebuilt thread shell fields by loading and decoding full message and activity history. the first fix replaced that with a scalar aggregate, but review found the aggregate still scanned and decoded every lifecycle row.

this revision moves normal runtime work to indexed point lookups plus one summary row. migration 42 safely upgrades databases that already recorded migration 41, ignores malformed json and non-string failure details, and repairs stale shell fields. live updates, owner-changing upserts, cursor replay, and revert reconstruction now use the same sqlite ordering and normalized state.

testing

• vp test run apps/server/src/orchestration apps/server/src/persistence (302 passed)
• vp run --filter t3 typecheck
• vp check <changed server files>
• git diff --check

regressions cover 10,000 matching lifecycle rows with large payloads, malformed lifecycle json, non-string failure details, activity-id and message-id replacement within and across threads, missing-summary replay, equal timestamps, stale/unknown response failures, migration 41-to-42 upgrades, shell-row reconciliation, and exact production query plans.

checklist

• i have performed a self-review of my changes
• i have added tests that prove my fix is effective
• new and existing tests pass locally

---

Note

Medium Risk
Touches projection correctness for thread list badges and pending-input counts across migrations, transactional upserts, and revert rebuild paths; wrong deltas would show stale UI state but is well-covered by tests.

Overview
Thread list shell summary fields (latest_user_message_at, pending_user_input_count, etc.) no longer rebuild by loading full message/activity history on every routine event.

Persistence: Activities now store normalized user_input_request_id / user_input_state and maintain a per-thread projection_thread_user_input_summaries row via transactional upserts (including cross-thread activity-id moves). Messages upsert refreshes latest_user_message_at on affected threads through an indexed “latest user message” query.

Projection pipeline: In-memory derivePendingUserInputCountFromActivities and the old refreshThreadShellSummary full-scan path are removed. Common events update shell fields incrementally; thread.reverted still calls rebuildThreadShellSummary, which uses scalar/count queries instead of hydrating payloads.

Migrations 41–42: Add lifecycle indexing, then upgrade to the summary table + covering indexes and backfill/reconcile existing projection_threads rows (including safe handling of malformed JSON).

^{Reviewed by Cursor Bugbot for commit 6dba7cc. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Bound thread shell-summary reads using pre-aggregated counts instead of full activity hydration

• Thread shell summary fields (pending_user_input_count, latest_user_message_at) are now maintained incrementally in projection_thread_user_input_summaries and directly on projection_threads, rather than being recomputed by scanning all activities/messages.
• Activity upserts and deletes in ProjectionThreadActivities.ts maintain per-thread pending counts via delta updates to the summary table, including correct handling of cross-thread activity moves.
• Message upserts and deletes in ProjectionThreadMessages.ts synchronize latest_user_message_at on projection_threads, including correcting the previous thread when a message moves.
• ProjectionPipeline.ts projection handlers now call targeted repository aggregates per event type; thread.reverted triggers a full rebuildThreadShellSummary using persisted aggregates.
• Migration 042 backfills user_input_request_id/user_input_state columns on activities, creates the summary table, and reconciles existing thread-level counts and timestamps.
• Risk: upserts for activities and messages now run in transactions with additional reads and writes, increasing per-event DB load.

^{Macroscope summarized 6dba7cc.}

[github-actions]

Thread transfer impact

✅ Thread transfer remains within every enforced ceiling.

ℹ️ The exact PR base did not have a successful artifact. Baseline uses the latest successful main measurement shown below.

Provider	Metric	Main baseline	This PR	Impact	PR ceiling
Codex	Total thread wire	11.3 KiB	12.4 KiB	+1.1 KiB (+9.9%)	15.1 KiB	✅
Codex	Thread snapshot wire	5.5 KiB	6.3 KiB	+837 B (+15.0%)	7.3 KiB	✅
Codex	Live turn WebSocket wire	5.9 KiB	6.2 KiB	+310 B (+5.2%)	7.8 KiB	✅
Codex	Live turn WebSocket decoded	49.7 KiB	52.4 KiB	+2.7 KiB (+5.3%)	66.4 KiB	✅
Codex	Live turn messages	16	10	−6 (−37.5%)	21	✅
Claude	Total thread wire	11.3 KiB	12.4 KiB	+1.1 KiB (+9.6%)	15.1 KiB	✅
Claude	Thread snapshot wire	5.5 KiB	6.3 KiB	+817 B (+14.6%)	7.3 KiB	✅
Claude	Live turn WebSocket wire	5.9 KiB	6.1 KiB	+301 B (+5.0%)	7.8 KiB	✅
Claude	Live turn WebSocket decoded	50.6 KiB	53.2 KiB	+2.7 KiB (+5.3%)	66.4 KiB	✅
Claude	Live turn messages	16	10	−6 (−37.5%)	21	✅

Baseline: 83d769f · PR result: 6dba7cc · 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: 99.9 KiB
• Claude decoded thread snapshot: 100.6 KiB

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

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — This PR introduces database schema changes (new columns, tables, indexes) and refactors shell summary tracking from in-memory full-collection scans to transactional incremental updates with delta tracking. The PR's own description labels it 'Medium Risk' affecting projection correctness, warranting human review.

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

[t3dotgg]

Note

🤖 GPT-5.6 Sol responding on behalf of Theo

Closing in favor of merged #8150, which removes repeated full-history reads from assistant messages and routine activities. The additional summary-state migration and lifecycle changes were not needed for that fix. Your work is credited in #8150.

[t3-code]

what changed

• normalize user-input request ids and state transitions when projecting activities
• maintain a one-row pending-input summary per thread through indexed old/new request lookups
• read latest user-message timestamps through a partial covering index
• repair old and new thread owners after destructive activity-id and message-id upserts
• reconcile existing shell rows in migration 42 and self-heal a missing lifecycle summary on replay

why

fixes#5719.

common assistant messages and routine activities previously rebuilt thread shell fields by loading and decoding full message and activity history. the first fix replaced that with a scalar aggregate, but review found the aggregate still scanned and decoded every lifecycle row.

this revision moves normal runtime work to indexed point lookups plus one summary row. migration 42 safely upgrades databases that already recorded migration 41, ignores malformed json and non-string failure details, and repairs stale shell fields. live updates, owner-changing upserts, cursor replay, and revert reconstruction now use the same sqlite ordering and normalized state.

testing

• vp test run apps/server/src/orchestration apps/server/src/persistence (302 passed)
• vp run --filter t3 typecheck
• vp check <changed server files>
• git diff --check

regressions cover 10,000 matching lifecycle rows with large payloads, malformed lifecycle json, non-string failure details, activity-id and message-id replacement within and across threads, missing-summary replay, equal timestamps, stale/unknown response failures, migration 41-to-42 upgrades, shell-row reconciliation, and exact production query plans.

checklist

• i have performed a self-review of my changes
• i have added tests that prove my fix is effective
• new and existing tests pass locally

---

Note

Medium Risk
Touches projection correctness for thread list badges and pending-input counts across migrations, transactional upserts, and revert rebuild paths; wrong deltas would show stale UI state but is well-covered by tests.

Overview
Thread list shell summary fields (latest_user_message_at, pending_user_input_count, etc.) no longer rebuild by loading full message/activity history on every routine event.

Persistence: Activities now store normalized user_input_request_id / user_input_state and maintain a per-thread projection_thread_user_input_summaries row via transactional upserts (including cross-thread activity-id moves). Messages upsert refreshes latest_user_message_at on affected threads through an indexed “latest user message” query.

Projection pipeline: In-memory derivePendingUserInputCountFromActivities and the old refreshThreadShellSummary full-scan path are removed. Common events update shell fields incrementally; thread.reverted still calls rebuildThreadShellSummary, which uses scalar/count queries instead of hydrating payloads.

Migrations 41–42: Add lifecycle indexing, then upgrade to the summary table + covering indexes and backfill/reconcile existing projection_threads rows (including safe handling of malformed JSON).

^{Reviewed by Cursor Bugbot for commit 6dba7cc. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Bound thread shell-summary reads using pre-aggregated counts instead of full activity hydration

• Thread shell summary fields (pending_user_input_count, latest_user_message_at) are now maintained incrementally in projection_thread_user_input_summaries and directly on projection_threads, rather than being recomputed by scanning all activities/messages.
• Activity upserts and deletes in ProjectionThreadActivities.ts maintain per-thread pending counts via delta updates to the summary table, including correct handling of cross-thread activity moves.
• Message upserts and deletes in ProjectionThreadMessages.ts synchronize latest_user_message_at on projection_threads, including correcting the previous thread when a message moves.
• ProjectionPipeline.ts projection handlers now call targeted repository aggregates per event type; thread.reverted triggers a full rebuildThreadShellSummary using persisted aggregates.
• Migration 042 backfills user_input_request_id/user_input_state columns on activities, creates the summary table, and reconciles existing thread-level counts and timestamps.
• Risk: upserts for activities and messages now run in transactions with additional reads and writes, increasing per-event DB load.

^{Macroscope summarized 6dba7cc.}

[github-actions]

Thread transfer impact

✅ Thread transfer remains within every enforced ceiling.

ℹ️ The exact PR base did not have a successful artifact. Baseline uses the latest successful main measurement shown below.

Provider	Metric	Main baseline	This PR	Impact	PR ceiling
Codex	Total thread wire	11.3 KiB	12.4 KiB	+1.1 KiB (+9.9%)	15.1 KiB	✅
Codex	Thread snapshot wire	5.5 KiB	6.3 KiB	+837 B (+15.0%)	7.3 KiB	✅
Codex	Live turn WebSocket wire	5.9 KiB	6.2 KiB	+310 B (+5.2%)	7.8 KiB	✅
Codex	Live turn WebSocket decoded	49.7 KiB	52.4 KiB	+2.7 KiB (+5.3%)	66.4 KiB	✅
Codex	Live turn messages	16	10	−6 (−37.5%)	21	✅
Claude	Total thread wire	11.3 KiB	12.4 KiB	+1.1 KiB (+9.6%)	15.1 KiB	✅
Claude	Thread snapshot wire	5.5 KiB	6.3 KiB	+817 B (+14.6%)	7.3 KiB	✅
Claude	Live turn WebSocket wire	5.9 KiB	6.1 KiB	+301 B (+5.0%)	7.8 KiB	✅
Claude	Live turn WebSocket decoded	50.6 KiB	53.2 KiB	+2.7 KiB (+5.3%)	66.4 KiB	✅
Claude	Live turn messages	16	10	−6 (−37.5%)	21	✅

Baseline: 83d769f · PR result: 6dba7cc · 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: 99.9 KiB
• Claude decoded thread snapshot: 100.6 KiB

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

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — This PR introduces database schema changes (new columns, tables, indexes) and refactors shell summary tracking from in-memory full-collection scans to transactional incremental updates with delta tracking. The PR's own description labels it 'Medium Risk' affecting projection correctness, warranting human review.

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

[t3dotgg]

Note

🤖 GPT-5.6 Sol responding on behalf of Theo

Closing in favor of merged #8150, which removes repeated full-history reads from assistant messages and routine activities. The additional summary-state migration and lifecycle changes were not needed for that fix. Your work is credited in #8150.

[t3-code]

what changed

• normalize user-input request ids and state transitions when projecting activities
• maintain a one-row pending-input summary per thread through indexed old/new request lookups
• read latest user-message timestamps through a partial covering index
• repair old and new thread owners after destructive activity-id and message-id upserts
• reconcile existing shell rows in migration 42 and self-heal a missing lifecycle summary on replay

why

fixes#5719.

common assistant messages and routine activities previously rebuilt thread shell fields by loading and decoding full message and activity history. the first fix replaced that with a scalar aggregate, but review found the aggregate still scanned and decoded every lifecycle row.

this revision moves normal runtime work to indexed point lookups plus one summary row. migration 42 safely upgrades databases that already recorded migration 41, ignores malformed json and non-string failure details, and repairs stale shell fields. live updates, owner-changing upserts, cursor replay, and revert reconstruction now use the same sqlite ordering and normalized state.

testing

• vp test run apps/server/src/orchestration apps/server/src/persistence (302 passed)
• vp run --filter t3 typecheck
• vp check <changed server files>
• git diff --check

regressions cover 10,000 matching lifecycle rows with large payloads, malformed lifecycle json, non-string failure details, activity-id and message-id replacement within and across threads, missing-summary replay, equal timestamps, stale/unknown response failures, migration 41-to-42 upgrades, shell-row reconciliation, and exact production query plans.

checklist

• i have performed a self-review of my changes
• i have added tests that prove my fix is effective
• new and existing tests pass locally

---

Note

Medium Risk
Touches projection correctness for thread list badges and pending-input counts across migrations, transactional upserts, and revert rebuild paths; wrong deltas would show stale UI state but is well-covered by tests.

Overview
Thread list shell summary fields (latest_user_message_at, pending_user_input_count, etc.) no longer rebuild by loading full message/activity history on every routine event.

Persistence: Activities now store normalized user_input_request_id / user_input_state and maintain a per-thread projection_thread_user_input_summaries row via transactional upserts (including cross-thread activity-id moves). Messages upsert refreshes latest_user_message_at on affected threads through an indexed “latest user message” query.

Projection pipeline: In-memory derivePendingUserInputCountFromActivities and the old refreshThreadShellSummary full-scan path are removed. Common events update shell fields incrementally; thread.reverted still calls rebuildThreadShellSummary, which uses scalar/count queries instead of hydrating payloads.

Migrations 41–42: Add lifecycle indexing, then upgrade to the summary table + covering indexes and backfill/reconcile existing projection_threads rows (including safe handling of malformed JSON).

^{Reviewed by Cursor Bugbot for commit 6dba7cc. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Bound thread shell-summary reads using pre-aggregated counts instead of full activity hydration

• Thread shell summary fields (pending_user_input_count, latest_user_message_at) are now maintained incrementally in projection_thread_user_input_summaries and directly on projection_threads, rather than being recomputed by scanning all activities/messages.
• Activity upserts and deletes in ProjectionThreadActivities.ts maintain per-thread pending counts via delta updates to the summary table, including correct handling of cross-thread activity moves.
• Message upserts and deletes in ProjectionThreadMessages.ts synchronize latest_user_message_at on projection_threads, including correcting the previous thread when a message moves.
• ProjectionPipeline.ts projection handlers now call targeted repository aggregates per event type; thread.reverted triggers a full rebuildThreadShellSummary using persisted aggregates.
• Migration 042 backfills user_input_request_id/user_input_state columns on activities, creates the summary table, and reconciles existing thread-level counts and timestamps.
• Risk: upserts for activities and messages now run in transactions with additional reads and writes, increasing per-event DB load.

^{Macroscope summarized 6dba7cc.}

[github-actions]

Thread transfer impact

✅ Thread transfer remains within every enforced ceiling.

ℹ️ The exact PR base did not have a successful artifact. Baseline uses the latest successful main measurement shown below.

Provider	Metric	Main baseline	This PR	Impact	PR ceiling
Codex	Total thread wire	11.3 KiB	12.4 KiB	+1.1 KiB (+9.9%)	15.1 KiB	✅
Codex	Thread snapshot wire	5.5 KiB	6.3 KiB	+837 B (+15.0%)	7.3 KiB	✅
Codex	Live turn WebSocket wire	5.9 KiB	6.2 KiB	+310 B (+5.2%)	7.8 KiB	✅
Codex	Live turn WebSocket decoded	49.7 KiB	52.4 KiB	+2.7 KiB (+5.3%)	66.4 KiB	✅
Codex	Live turn messages	16	10	−6 (−37.5%)	21	✅
Claude	Total thread wire	11.3 KiB	12.4 KiB	+1.1 KiB (+9.6%)	15.1 KiB	✅
Claude	Thread snapshot wire	5.5 KiB	6.3 KiB	+817 B (+14.6%)	7.3 KiB	✅
Claude	Live turn WebSocket wire	5.9 KiB	6.1 KiB	+301 B (+5.0%)	7.8 KiB	✅
Claude	Live turn WebSocket decoded	50.6 KiB	53.2 KiB	+2.7 KiB (+5.3%)	66.4 KiB	✅
Claude	Live turn messages	16	10	−6 (−37.5%)	21	✅

Baseline: 83d769f · PR result: 6dba7cc · 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: 99.9 KiB
• Claude decoded thread snapshot: 100.6 KiB

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

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — This PR introduces database schema changes (new columns, tables, indexes) and refactors shell summary tracking from in-memory full-collection scans to transactional incremental updates with delta tracking. The PR's own description labels it 'Medium Risk' affecting projection correctness, warranting human review.

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

[t3dotgg]

Note

🤖 GPT-5.6 Sol responding on behalf of Theo

Closing in favor of merged #8150, which removes repeated full-history reads from assistant messages and routine activities. The additional summary-state migration and lifecycle changes were not needed for that fix. Your work is credited in #8150.

[t3-code]

what changed

• normalize user-input request ids and state transitions when projecting activities
• maintain a one-row pending-input summary per thread through indexed old/new request lookups
• read latest user-message timestamps through a partial covering index
• repair old and new thread owners after destructive activity-id and message-id upserts
• reconcile existing shell rows in migration 42 and self-heal a missing lifecycle summary on replay

why

fixes#5719.

common assistant messages and routine activities previously rebuilt thread shell fields by loading and decoding full message and activity history. the first fix replaced that with a scalar aggregate, but review found the aggregate still scanned and decoded every lifecycle row.

this revision moves normal runtime work to indexed point lookups plus one summary row. migration 42 safely upgrades databases that already recorded migration 41, ignores malformed json and non-string failure details, and repairs stale shell fields. live updates, owner-changing upserts, cursor replay, and revert reconstruction now use the same sqlite ordering and normalized state.

testing

• vp test run apps/server/src/orchestration apps/server/src/persistence (302 passed)
• vp run --filter t3 typecheck
• vp check <changed server files>
• git diff --check

regressions cover 10,000 matching lifecycle rows with large payloads, malformed lifecycle json, non-string failure details, activity-id and message-id replacement within and across threads, missing-summary replay, equal timestamps, stale/unknown response failures, migration 41-to-42 upgrades, shell-row reconciliation, and exact production query plans.

checklist

• i have performed a self-review of my changes
• i have added tests that prove my fix is effective
• new and existing tests pass locally

---

Note

Medium Risk
Touches projection correctness for thread list badges and pending-input counts across migrations, transactional upserts, and revert rebuild paths; wrong deltas would show stale UI state but is well-covered by tests.

Overview
Thread list shell summary fields (latest_user_message_at, pending_user_input_count, etc.) no longer rebuild by loading full message/activity history on every routine event.

Persistence: Activities now store normalized user_input_request_id / user_input_state and maintain a per-thread projection_thread_user_input_summaries row via transactional upserts (including cross-thread activity-id moves). Messages upsert refreshes latest_user_message_at on affected threads through an indexed “latest user message” query.

Projection pipeline: In-memory derivePendingUserInputCountFromActivities and the old refreshThreadShellSummary full-scan path are removed. Common events update shell fields incrementally; thread.reverted still calls rebuildThreadShellSummary, which uses scalar/count queries instead of hydrating payloads.

Migrations 41–42: Add lifecycle indexing, then upgrade to the summary table + covering indexes and backfill/reconcile existing projection_threads rows (including safe handling of malformed JSON).

^{Reviewed by Cursor Bugbot for commit 6dba7cc. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Bound thread shell-summary reads using pre-aggregated counts instead of full activity hydration

• Thread shell summary fields (pending_user_input_count, latest_user_message_at) are now maintained incrementally in projection_thread_user_input_summaries and directly on projection_threads, rather than being recomputed by scanning all activities/messages.
• Activity upserts and deletes in ProjectionThreadActivities.ts maintain per-thread pending counts via delta updates to the summary table, including correct handling of cross-thread activity moves.
• Message upserts and deletes in ProjectionThreadMessages.ts synchronize latest_user_message_at on projection_threads, including correcting the previous thread when a message moves.
• ProjectionPipeline.ts projection handlers now call targeted repository aggregates per event type; thread.reverted triggers a full rebuildThreadShellSummary using persisted aggregates.
• Migration 042 backfills user_input_request_id/user_input_state columns on activities, creates the summary table, and reconciles existing thread-level counts and timestamps.
• Risk: upserts for activities and messages now run in transactions with additional reads and writes, increasing per-event DB load.

^{Macroscope summarized 6dba7cc.}

[github-actions]

Thread transfer impact

✅ Thread transfer remains within every enforced ceiling.

ℹ️ The exact PR base did not have a successful artifact. Baseline uses the latest successful main measurement shown below.

Provider	Metric	Main baseline	This PR	Impact	PR ceiling
Codex	Total thread wire	11.3 KiB	12.4 KiB	+1.1 KiB (+9.9%)	15.1 KiB	✅
Codex	Thread snapshot wire	5.5 KiB	6.3 KiB	+837 B (+15.0%)	7.3 KiB	✅
Codex	Live turn WebSocket wire	5.9 KiB	6.2 KiB	+310 B (+5.2%)	7.8 KiB	✅
Codex	Live turn WebSocket decoded	49.7 KiB	52.4 KiB	+2.7 KiB (+5.3%)	66.4 KiB	✅
Codex	Live turn messages	16	10	−6 (−37.5%)	21	✅
Claude	Total thread wire	11.3 KiB	12.4 KiB	+1.1 KiB (+9.6%)	15.1 KiB	✅
Claude	Thread snapshot wire	5.5 KiB	6.3 KiB	+817 B (+14.6%)	7.3 KiB	✅
Claude	Live turn WebSocket wire	5.9 KiB	6.1 KiB	+301 B (+5.0%)	7.8 KiB	✅
Claude	Live turn WebSocket decoded	50.6 KiB	53.2 KiB	+2.7 KiB (+5.3%)	66.4 KiB	✅
Claude	Live turn messages	16	10	−6 (−37.5%)	21	✅

Baseline: 83d769f · PR result: 6dba7cc · 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: 99.9 KiB
• Claude decoded thread snapshot: 100.6 KiB

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

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — This PR introduces database schema changes (new columns, tables, indexes) and refactors shell summary tracking from in-memory full-collection scans to transactional incremental updates with delta tracking. The PR's own description labels it 'Medium Risk' affecting projection correctness, warranting human review.

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

[t3dotgg]

Note

🤖 GPT-5.6 Sol responding on behalf of Theo

Closing in favor of merged #8150, which removes repeated full-history reads from assistant messages and routine activities. The additional summary-state migration and lifecycle changes were not needed for that fix. Your work is credited in #8150.

[t3-code]

what changed

• normalize user-input request ids and state transitions when projecting activities
• maintain a one-row pending-input summary per thread through indexed old/new request lookups
• read latest user-message timestamps through a partial covering index
• repair old and new thread owners after destructive activity-id and message-id upserts
• reconcile existing shell rows in migration 42 and self-heal a missing lifecycle summary on replay

why

fixes#5719.

common assistant messages and routine activities previously rebuilt thread shell fields by loading and decoding full message and activity history. the first fix replaced that with a scalar aggregate, but review found the aggregate still scanned and decoded every lifecycle row.

this revision moves normal runtime work to indexed point lookups plus one summary row. migration 42 safely upgrades databases that already recorded migration 41, ignores malformed json and non-string failure details, and repairs stale shell fields. live updates, owner-changing upserts, cursor replay, and revert reconstruction now use the same sqlite ordering and normalized state.

testing

• vp test run apps/server/src/orchestration apps/server/src/persistence (302 passed)
• vp run --filter t3 typecheck
• vp check <changed server files>
• git diff --check

regressions cover 10,000 matching lifecycle rows with large payloads, malformed lifecycle json, non-string failure details, activity-id and message-id replacement within and across threads, missing-summary replay, equal timestamps, stale/unknown response failures, migration 41-to-42 upgrades, shell-row reconciliation, and exact production query plans.

checklist

• i have performed a self-review of my changes
• i have added tests that prove my fix is effective
• new and existing tests pass locally

---

Note

Medium Risk
Touches projection correctness for thread list badges and pending-input counts across migrations, transactional upserts, and revert rebuild paths; wrong deltas would show stale UI state but is well-covered by tests.

Overview
Thread list shell summary fields (latest_user_message_at, pending_user_input_count, etc.) no longer rebuild by loading full message/activity history on every routine event.

Persistence: Activities now store normalized user_input_request_id / user_input_state and maintain a per-thread projection_thread_user_input_summaries row via transactional upserts (including cross-thread activity-id moves). Messages upsert refreshes latest_user_message_at on affected threads through an indexed “latest user message” query.

Projection pipeline: In-memory derivePendingUserInputCountFromActivities and the old refreshThreadShellSummary full-scan path are removed. Common events update shell fields incrementally; thread.reverted still calls rebuildThreadShellSummary, which uses scalar/count queries instead of hydrating payloads.

Migrations 41–42: Add lifecycle indexing, then upgrade to the summary table + covering indexes and backfill/reconcile existing projection_threads rows (including safe handling of malformed JSON).

^{Reviewed by Cursor Bugbot for commit 6dba7cc. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Bound thread shell-summary reads using pre-aggregated counts instead of full activity hydration

• Thread shell summary fields (pending_user_input_count, latest_user_message_at) are now maintained incrementally in projection_thread_user_input_summaries and directly on projection_threads, rather than being recomputed by scanning all activities/messages.
• Activity upserts and deletes in ProjectionThreadActivities.ts maintain per-thread pending counts via delta updates to the summary table, including correct handling of cross-thread activity moves.
• Message upserts and deletes in ProjectionThreadMessages.ts synchronize latest_user_message_at on projection_threads, including correcting the previous thread when a message moves.
• ProjectionPipeline.ts projection handlers now call targeted repository aggregates per event type; thread.reverted triggers a full rebuildThreadShellSummary using persisted aggregates.
• Migration 042 backfills user_input_request_id/user_input_state columns on activities, creates the summary table, and reconciles existing thread-level counts and timestamps.
• Risk: upserts for activities and messages now run in transactions with additional reads and writes, increasing per-event DB load.

^{Macroscope summarized 6dba7cc.}

[github-actions]

Thread transfer impact

✅ Thread transfer remains within every enforced ceiling.

ℹ️ The exact PR base did not have a successful artifact. Baseline uses the latest successful main measurement shown below.

Provider	Metric	Main baseline	This PR	Impact	PR ceiling
Codex	Total thread wire	11.3 KiB	12.4 KiB	+1.1 KiB (+9.9%)	15.1 KiB	✅
Codex	Thread snapshot wire	5.5 KiB	6.3 KiB	+837 B (+15.0%)	7.3 KiB	✅
Codex	Live turn WebSocket wire	5.9 KiB	6.2 KiB	+310 B (+5.2%)	7.8 KiB	✅
Codex	Live turn WebSocket decoded	49.7 KiB	52.4 KiB	+2.7 KiB (+5.3%)	66.4 KiB	✅
Codex	Live turn messages	16	10	−6 (−37.5%)	21	✅
Claude	Total thread wire	11.3 KiB	12.4 KiB	+1.1 KiB (+9.6%)	15.1 KiB	✅
Claude	Thread snapshot wire	5.5 KiB	6.3 KiB	+817 B (+14.6%)	7.3 KiB	✅
Claude	Live turn WebSocket wire	5.9 KiB	6.1 KiB	+301 B (+5.0%)	7.8 KiB	✅
Claude	Live turn WebSocket decoded	50.6 KiB	53.2 KiB	+2.7 KiB (+5.3%)	66.4 KiB	✅
Claude	Live turn messages	16	10	−6 (−37.5%)	21	✅

Baseline: 83d769f · PR result: 6dba7cc · 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: 99.9 KiB
• Claude decoded thread snapshot: 100.6 KiB

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

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — This PR introduces database schema changes (new columns, tables, indexes) and refactors shell summary tracking from in-memory full-collection scans to transactional incremental updates with delta tracking. The PR's own description labels it 'Medium Risk' affecting projection correctness, warranting human review.

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

[t3dotgg]

Note

🤖 GPT-5.6 Sol responding on behalf of Theo

Closing in favor of merged #8150, which removes repeated full-history reads from assistant messages and routine activities. The additional summary-state migration and lifecycle changes were not needed for that fix. Your work is credited in #8150.

[t3-code]

what changed

• normalize user-input request ids and state transitions when projecting activities
• maintain a one-row pending-input summary per thread through indexed old/new request lookups
• read latest user-message timestamps through a partial covering index
• repair old and new thread owners after destructive activity-id and message-id upserts
• reconcile existing shell rows in migration 42 and self-heal a missing lifecycle summary on replay

why

fixes#5719.

common assistant messages and routine activities previously rebuilt thread shell fields by loading and decoding full message and activity history. the first fix replaced that with a scalar aggregate, but review found the aggregate still scanned and decoded every lifecycle row.

this revision moves normal runtime work to indexed point lookups plus one summary row. migration 42 safely upgrades databases that already recorded migration 41, ignores malformed json and non-string failure details, and repairs stale shell fields. live updates, owner-changing upserts, cursor replay, and revert reconstruction now use the same sqlite ordering and normalized state.

testing

• vp test run apps/server/src/orchestration apps/server/src/persistence (302 passed)
• vp run --filter t3 typecheck
• vp check <changed server files>
• git diff --check

regressions cover 10,000 matching lifecycle rows with large payloads, malformed lifecycle json, non-string failure details, activity-id and message-id replacement within and across threads, missing-summary replay, equal timestamps, stale/unknown response failures, migration 41-to-42 upgrades, shell-row reconciliation, and exact production query plans.

checklist

• i have performed a self-review of my changes
• i have added tests that prove my fix is effective
• new and existing tests pass locally

---

Note

Medium Risk
Touches projection correctness for thread list badges and pending-input counts across migrations, transactional upserts, and revert rebuild paths; wrong deltas would show stale UI state but is well-covered by tests.

Overview
Thread list shell summary fields (latest_user_message_at, pending_user_input_count, etc.) no longer rebuild by loading full message/activity history on every routine event.

Persistence: Activities now store normalized user_input_request_id / user_input_state and maintain a per-thread projection_thread_user_input_summaries row via transactional upserts (including cross-thread activity-id moves). Messages upsert refreshes latest_user_message_at on affected threads through an indexed “latest user message” query.

Projection pipeline: In-memory derivePendingUserInputCountFromActivities and the old refreshThreadShellSummary full-scan path are removed. Common events update shell fields incrementally; thread.reverted still calls rebuildThreadShellSummary, which uses scalar/count queries instead of hydrating payloads.

Migrations 41–42: Add lifecycle indexing, then upgrade to the summary table + covering indexes and backfill/reconcile existing projection_threads rows (including safe handling of malformed JSON).

^{Reviewed by Cursor Bugbot for commit 6dba7cc. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Bound thread shell-summary reads using pre-aggregated counts instead of full activity hydration

• Thread shell summary fields (pending_user_input_count, latest_user_message_at) are now maintained incrementally in projection_thread_user_input_summaries and directly on projection_threads, rather than being recomputed by scanning all activities/messages.
• Activity upserts and deletes in ProjectionThreadActivities.ts maintain per-thread pending counts via delta updates to the summary table, including correct handling of cross-thread activity moves.
• Message upserts and deletes in ProjectionThreadMessages.ts synchronize latest_user_message_at on projection_threads, including correcting the previous thread when a message moves.
• ProjectionPipeline.ts projection handlers now call targeted repository aggregates per event type; thread.reverted triggers a full rebuildThreadShellSummary using persisted aggregates.
• Migration 042 backfills user_input_request_id/user_input_state columns on activities, creates the summary table, and reconciles existing thread-level counts and timestamps.
• Risk: upserts for activities and messages now run in transactions with additional reads and writes, increasing per-event DB load.

^{Macroscope summarized 6dba7cc.}

[github-actions]

Thread transfer impact

✅ Thread transfer remains within every enforced ceiling.

ℹ️ The exact PR base did not have a successful artifact. Baseline uses the latest successful main measurement shown below.

Provider	Metric	Main baseline	This PR	Impact	PR ceiling
Codex	Total thread wire	11.3 KiB	12.4 KiB	+1.1 KiB (+9.9%)	15.1 KiB	✅
Codex	Thread snapshot wire	5.5 KiB	6.3 KiB	+837 B (+15.0%)	7.3 KiB	✅
Codex	Live turn WebSocket wire	5.9 KiB	6.2 KiB	+310 B (+5.2%)	7.8 KiB	✅
Codex	Live turn WebSocket decoded	49.7 KiB	52.4 KiB	+2.7 KiB (+5.3%)	66.4 KiB	✅
Codex	Live turn messages	16	10	−6 (−37.5%)	21	✅
Claude	Total thread wire	11.3 KiB	12.4 KiB	+1.1 KiB (+9.6%)	15.1 KiB	✅
Claude	Thread snapshot wire	5.5 KiB	6.3 KiB	+817 B (+14.6%)	7.3 KiB	✅
Claude	Live turn WebSocket wire	5.9 KiB	6.1 KiB	+301 B (+5.0%)	7.8 KiB	✅
Claude	Live turn WebSocket decoded	50.6 KiB	53.2 KiB	+2.7 KiB (+5.3%)	66.4 KiB	✅
Claude	Live turn messages	16	10	−6 (−37.5%)	21	✅

Baseline: 83d769f · PR result: 6dba7cc · 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: 99.9 KiB
• Claude decoded thread snapshot: 100.6 KiB

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

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — This PR introduces database schema changes (new columns, tables, indexes) and refactors shell summary tracking from in-memory full-collection scans to transactional incremental updates with delta tracking. The PR's own description labels it 'Medium Risk' affecting projection correctness, warranting human review.

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

[t3dotgg]

Note

🤖 GPT-5.6 Sol responding on behalf of Theo

Closing in favor of merged #8150, which removes repeated full-history reads from assistant messages and routine activities. The additional summary-state migration and lifecycle changes were not needed for that fix. Your work is credited in #8150.