perf(server): persist the wire projection for streaming tool.updated data

[mInrOz]

Fixes #6673. Related: #6608 / #5855 (read side of the same event flood), #5550 (retention), #5651 (assistant message write path). Decision date: 2026-08-15.

Outcome

Non-terminal tool.updated activities now persist the same projected data that clients receive on the wire. projectActivityPayload already runs in ws.ts and in http.ts, so no client can receive the full data of any activity today. This PR applies the same projection at ingestion time, before the payload reaches orchestration_events and projection_thread_activities.

This PR does not change: terminal tool.completed payloads (still persisted in full), the event count per tool call, any schema, any existing rows, or any client-visible payload.

Before and after

Failure mode before	Mechanism after
A streaming update persists the full accumulated rawOutput/content, so one tool call with N updates writes O(N²) bytes, twice. Measured: one 65 KB tool result persisted 238.7 MB across 2,226 updates (3,772×); one tool call produced 357 MB of payload.	A non-terminal update persists the projected form: toolCallId, kind, command, changed files, and a one-line rawOutput summary. Bytes per update are bounded (~1 KB), so a tool call writes O(N) bytes.
The event store grows without bound from streaming payloads (~235 MB/day measured on one instance), which multiplies the full-thread rescan cost fixed by #6608.	Streaming updates no longer carry payload bulk into the event store. Terminal payloads remain the only large rows.

Decisions taken

• Reuse projectActivityPayload instead of adding a size cap. A cap needs a constant and keeps a second copy of the slimming rules. Reuse keeps one invariant: for streaming updates, persistence stores what clients can receive. The projection's own doc comment ("full payloads remain in persistence") described the pre-[Bug]: Streaming tool.updated persists the full accumulated rawOutput on every delta — O(N²) bytes and rows per tool call #6673 intent; this PR revises that intent for non-terminal updates only.
• item.completed stays untouched. The terminal payload is the record of what the tool produced. It is one row per call, so it does not amplify.
• Event count is not reduced. Debouncing emissions or reusing a stable activity_id per toolCallId changes what clients observe and belongs in a separate change. Deferred; noted in [Bug]: Streaming tool.updated persists the full accumulated rawOutput on every delta — O(N²) bytes and rows per tool call #6673 as a follow-up.
• Interrupted tool calls keep only projected data for their last update. Accepted: clients could never render more than the projected form anyway.

Finding disposition (#6673)

• O(N²) bytes per tool call, stored twice → fixed here, regression-tested.
• One activity row per update (O(N) rows) → deferred; requires an id-semantics change (see [Bug]: Streaming tool.updated persists the full accumulated rawOutput on every delta — O(N²) bytes and rows per tool call #6673 suggested follow-up).
• shouldEmitToolCallUpdate gates only on detail → not changed; with bounded payloads the extra emissions cost little, and fewer emissions would change client behavior.

Verification

Ran on Linux, Node v24.18.1, pnpm 11.10.0:

• pnpm exec vp test run src/orchestration/Layers/ProviderRuntimeIngestion.activity.test.ts — 4 passed (2 new: projected persistence for tool.updated; full payload kept for tool.completed).
• pnpm exec vp test run src/orchestration/Layers/ProviderRuntimeIngestion.test.ts src/orchestration/Layers/ProviderRuntimeIngestion.approval.test.ts src/orchestration/ActivityPayloadProjection.test.ts — 52 passed.
• pnpm exec tsgo --noEmit in apps/server — no errors (pre-existing suggestions in unrelated files only).

Not run: the full monorepo suite (left to CI) and a production soak (moves to the rollout gate below).

Rollout and proof gates

We run t3 on self-hosted instances with the exact workload from #6673 (render jobs with progress-bar output). Ordered steps to produce production proof:

1. Deploy a build of this branch to an idle instance.
2. Run a chatty render job to completion.
3. Compare SELECT count(*), sum(length(payload_json)) FROM projection_thread_activities WHERE thread_id = ? against an unpatched run of the same job. Expected: similar row count, payload bytes down by >100×.
4. Report the numbers on this PR.

Rollback: reinstall the released npm build. The change is write-path only; there is no schema change and old rows are untouched, so nothing durable is lost by rolling back.

🤖 Generated with Claude Code

---

Note

Medium Risk
Write-path change to persisted activity payloads for streaming tool updates; behavior aligns with existing ws/http projection but could affect any internal reader that expected full in-progress data in the DB.

Overview
Fixes O(N²) storage from streaming tool runs by persisting the same slim data clients already get on the wire for non-terminal tool.updated activities, instead of the full accumulated stdout/content on every chunk.

runtimeEventToActivities now runs projectActivityPayload on item.updated tool lifecycle events before rows hit the event store and projection_thread_activities. item.completed is unchanged and still stores the full terminal payload. Event count and client-visible payloads are unchanged; only what gets written on the ingestion path for in-progress updates.

Regression tests assert projected tool.updated data (bounded size, one-line rawOutput) and full streamingData on tool.completed.

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

Note

Project wire payload for streaming tool.updated activities to avoid quadratic growth

Streaming tool output accumulates over time, so persisting the full data payload on every item.updated event causes storage to grow quadratically with stream length. runtimeEventToActivities in ProviderRuntimeIngestion.ts now wraps item.updated tool activities with projectActivityPayload, which truncates raw output and omits content fields. Terminal item.completed events are unaffected and still persist the full payload.

^{Macroscope summarized 66d0ce4.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 09579cc8-4eac-448e-87e2-8372557c63b1

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

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

[macroscopeapp]

Approvability

Verdict: Approved 66d0ce4

Performance optimization applying an existing projection function to streaming tool updates at persistence time, reducing O(N²) storage overhead. Full data is maintained for completed events. Self-contained with comprehensive tests.

^{You can customize Macroscope's approvability policy. Learn more.}

[mInrOz]

Rollout-gate results from our idle instance (Linux LXC, Node v24.19.0, 2026-08-15).

A/B benchmark through the real persistence stack

We ran one identical synthetic tool call through runtimeEventToActivities → OrchestrationEventStore.append → OrchestrationProjectionPipeline.projectEvent, on this branch (66d0ce4) and on its parent (f0ebc62). The harness is an untracked test file on the repo's own test layers (SqlitePersistenceMemory + OrchestrationEventStoreLive + OrchestrationProjectionPipelineLive), so the SQL write path is the production code path. Workload: 300 item.updated events, each adds 10 output lines; final rawOutput is 76,892 bytes; one terminal item.completed carries the full output.

metric	parent f0ebc62	this branch	change
projection_thread_activities bytes	24,018,619	190,135	126× less
orchestration_events bytes	24,074,799	246,315	98× less
total persisted bytes	48.1 MB	436 KB	110× less
bytes persisted / final output	625×	5.7×	—
append+project wall time	8,719 ms	979 ms	8.9× faster
activity rows	301	301	unchanged

The row count is unchanged, as intended: this PR bounds bytes, not event count. The wall-time gain is a side effect of smaller JSON through the synchronous SQL path.

Deploy smoke

pnpm run build:bundle on this branch; ran dist/bin.mjs serve against a fresh --base-dir with the released web client assets linked in. Result: "Migrations ran successfully", "Listening on http://127.0.0.1:3782", GET / and GET /api/health return 200. Stopped after the probe.