Fix quadratic thread-reopen replay: batch client apply + cap server resume gap

[colonelpanic8]

Fixes #4596.

Reopening a thread with a large persisted-event backlog visibly re-replayed the whole backlog: the server streamed every event since the client's cursor individually, and the client published a new state (full timeline re-derive + re-render) per event. Real threads carry thousands of events — a sampled database had a thread with 4,830 (4,170 of them thread.activity-appended, with assistant streaming off) — making reopen cost quadratic and freezing the UI for tens of seconds to minutes.

The fix (two independent halves)

• Client (packages/client-runtime/src/state/threads.ts): subscription items now flow through a queue; the apply loop drains one item plus everything that accumulated (giving an in-flight burst a few scheduler turns to land) and folds the whole batch through the reducer with a single state publication. Live one-at-a-time updates publish immediately; no timers, so a quiet stream gains no latency.
• Server (apps/server/src/ws.ts): subscribeThread resume now mirrors the shell stream's gap cap — beyond THREAD_RESUME_MAX_GAP (1000) events (or a cursor ahead of the head), it sends a fresh snapshot plus the live tail instead of an unbounded replay. In-range replays are bounded to the captured head instead of Number.MAX_SAFE_INTEGER.

Evidence

• The threadReplayPerf gauge (added here) drives the real resume path: 2000 replayed deltas previously produced 2,002 state publications; the test now enforces < 200.
• The /perf.html playground (added here) mounts the real MessagesTimeline and showed one-publication-per-event costs ~37s for a real-thread mix (350 message + 4,200 activity events) and ~212s for 2000 streaming deltas; batched application measured ~5.4s / ~8.1s respectively (7–26×).
• New server test: subscribeThread sends a fresh snapshot instead of replaying a large gap.

Also in this PR (repro tooling, first four commits)

• threadTimelineModel.ts: pure extraction of ChatView's timeline derivation (behavior-identical) so the pipeline runs outside the app shell.
• /perf.html dev playground replaying synthetic delta/activity backlogs through the real reducer + timeline with commit/stall metrics.
• threadReplayPerf.test.ts unit gauge and a chunked-streaming mode for acp-mock-agent.ts (T3_ACP_PROMPT_RESPONSE_CHUNK_COUNT) for end-to-end reproduction.

Tests: client-runtime 473/473, server server.test.ts 113/113, web timeline suites 101/101; typechecks clean across touched packages.

🤖 Generated with Claude Code

---

Note

Medium Risk
Changes core thread WebSocket resume and client state publication semantics; mitigated by mirroring the existing shell gap cap, new server/client tests, and perf guards that limit emissions during large replays.

Overview
Fixes quadratic cost when reopening threads with large persisted-event backlogs (streaming deltas and tool activities).

Server: subscribeThread resume now uses THREAD_RESUME_MAX_GAP (1000), matching the shell stream. Gaps larger than that (or an invalid cursor) skip per-event replay and send a fresh thread snapshot plus the live tail; in-range catch-up reads only through the captured head instead of an unbounded range.

Client: Thread subscription items go through a queue and drain-based batching loop that folds bursts into applyItems and one state publication per batch (live single events still publish promptly). Resubscribe clears stale queued items via a generation counter and an apply lock.

Supporting changes: Timeline derivation is moved to threadTimelineModel.ts (same behavior in ChatView). Adds /perf.html replay playground, threadReplayPerf benchmarks, shared sync test harness, and optional chunked mock-agent responses for reproducing heavy streaming histories.

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

Note

Fix quadratic thread-reopen replay by batching client state updates and capping server replay gap

• threads.ts: replaces per-event state publication with drain-based batching that folds up to 32 items into a single state emit, eliminating O(n) React renders during replay
• ws.ts: caps server-side replay at THREAD_RESUME_MAX_GAP = 1_000 events; gaps exceeding this send a fresh snapshot instead of replaying all missed events
• Extracts timeline derivation helpers into threadTimelineModel.ts and uses them in ChatView, enabling accurate profiling via the new ThreadReplayPlayground
• Behavioral Change: live single events still publish promptly; resume replay now emits far fewer intermediate states, which may affect any code observing intermediate thread states during reconnect

^{Macroscope summarized 5eaec3e.}

[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: eaebf1df-6aa5-4d51-b2e6-5c57cdac773b

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

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

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.}

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 2 potential issues.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 543cd7d. Configure here.}

[macroscopeapp]

Approvability

Verdict: Needs human review

This PR makes significant changes to core thread synchronization machinery - introducing server-side replay gap caps and client-side event batching with new concurrency primitives (semaphores, generation tracking, queues). While fixing a real quadratic performance issue, the architectural changes to when snapshots vs events are used and how state publications are batched warrant careful human review.

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