perf(client): batch large thread sync updates - #5344
Open
danvernon wants to merge 2 commits into
Open
Conversation
|
Important Review skippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
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. Comment |
github-actions
Bot
added
vouch:unvouched
![macroscopeapp[bot]](https://avatars.githubusercontent.com/in/900172?s=60&v=4){kind=small}
danvernon
marked this pull request as ready for review
August 4, 2026 16:53
Contributor
ApprovabilityVerdict: Needs human review This performance optimization changes the timing characteristics of thread state synchronization by batching updates. While the tests cover key scenarios, the change to a core sync mechanism by an author new to this file warrants human review to verify the batching approach is safe across all edge cases. You can customize Macroscope's approvability policy. Learn more. |
patroza
pushed a commit
to patroza/t3code
that referenced
this pull request
Aug 5, 2026
Imported from pingdotgg#5344 at source SHA 783fd02 (commits b623dc2 + 783fd02 squashed into one provenance commit). Imported behavior: - `reduceThreadStreamItems`, a pure reducer that folds a batch of thread stream items into one state and one persistable snapshot. - `Stream.groupedWithin(64, 16ms)` on the live subscription so a burst of thread events publishes the `SubscriptionRef` once instead of per event, and web/mobile stop rebuilding large thread views per streamed event. - `eventBatchSize` on `EnvironmentThreadStateOptions`, plus the upstream regression tests for ordered single-publication bursts and for persisting a settled snapshot when a batch ends with a non-persistable turn start. Local adaptations: - Kept our `httpSnapshotLoadAttempted` guard around the HTTP snapshot fallback; the call now goes through `applyItems([...])`. - Restored `setDeleted` (removed upstream) for the terminal `thread-deleted` subscription failure, which never reaches the item stream and so cannot go through the batch reducer. Cache removal is shared with the reducer path via `removeCachedThread`. Excluded: - `tasks/todo.md`, the author's scratch checklist. Follow-up (fork/changes, not this layer): our `reload-required` branch and `reloadFromServer` are built on the deleted `setThread`, so rebasing fork/changes onto this layer must re-express them against the reducer (split the batch at the reload point, then re-enter `applyItems` with the remainder).
patroza
added a commit
to patroza/t3code
that referenced
this pull request
Aug 5, 2026
… (#328) Imported from pingdotgg#5344 at source SHA 783fd02 (commits b623dc2 + 783fd02 squashed into one provenance commit). Imported behavior: - `reduceThreadStreamItems`, a pure reducer that folds a batch of thread stream items into one state and one persistable snapshot. - `Stream.groupedWithin(64, 16ms)` on the live subscription so a burst of thread events publishes the `SubscriptionRef` once instead of per event, and web/mobile stop rebuilding large thread views per streamed event. - `eventBatchSize` on `EnvironmentThreadStateOptions`, plus the upstream regression tests for ordered single-publication bursts and for persisting a settled snapshot when a batch ends with a non-persistable turn start. Local adaptations: - Kept our `httpSnapshotLoadAttempted` guard around the HTTP snapshot fallback; the call now goes through `applyItems([...])`. - Restored `setDeleted` (removed upstream) for the terminal `thread-deleted` subscription failure, which never reaches the item stream and so cannot go through the batch reducer. Cache removal is shared with the reducer path via `removeCachedThread`. Excluded: - `tasks/todo.md`, the author's scratch checklist. Follow-up (fork/changes, not this layer): our `reload-required` branch and `reloadFromServer` are built on the deleted `setThread`, so rebasing fork/changes onto this layer must re-express them against the reducer (split the batch at the reload point, then re-enter `applyItems` with the remainder). Co-authored-by: T3 Code PR Stack <41898282+github-actions[bot]@users.noreply.github.com>
patroza
added a commit
to patroza/t3code
that referenced
this pull request
Aug 5, 2026
… (#328) Imported from pingdotgg#5344 at source SHA 783fd02 (commits b623dc2 + 783fd02 squashed into one provenance commit). Imported behavior: - `reduceThreadStreamItems`, a pure reducer that folds a batch of thread stream items into one state and one persistable snapshot. - `Stream.groupedWithin(64, 16ms)` on the live subscription so a burst of thread events publishes the `SubscriptionRef` once instead of per event, and web/mobile stop rebuilding large thread views per streamed event. - `eventBatchSize` on `EnvironmentThreadStateOptions`, plus the upstream regression tests for ordered single-publication bursts and for persisting a settled snapshot when a batch ends with a non-persistable turn start. Local adaptations: - Kept our `httpSnapshotLoadAttempted` guard around the HTTP snapshot fallback; the call now goes through `applyItems([...])`. - Restored `setDeleted` (removed upstream) for the terminal `thread-deleted` subscription failure, which never reaches the item stream and so cannot go through the batch reducer. Cache removal is shared with the reducer path via `removeCachedThread`. Excluded: - `tasks/todo.md`, the author's scratch checklist. Follow-up (fork/changes, not this layer): our `reload-required` branch and `reloadFromServer` are built on the deleted `setThread`, so rebasing fork/changes onto this layer must re-express them against the reducer (split the batch at the reload point, then re-enter `applyItems` with the remainder). Co-authored-by: T3 Code PR Stack <41898282+github-actions[bot]@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Why
Large threads can produce many message and activity updates. Previously each event updated the shared
SubscriptionRef, causing the web and mobile clients to repeatedly rebuild large thread views during synchronization.Validation
./node_modules/.bin/vp test run packages/client-runtime/src/state/threads-sync.test.ts./node_modules/.bin/vp test run packages/client-runtime/src/state/threadReducer.test.ts packages/client-runtime/src/state/threads-atoms.test.tsThe PR intentionally focuses on client-side publication cost; server snapshot/replay and per-event reducer optimizations remain separate follow-up work.
Note
Batch large thread sync updates to reduce state publications in
EnvironmentThreadStatereduceThreadStreamItems, a pure reducer that processes a batch ofOrchestrationThreadStreamItemevents and produces a single updated state and a persistable snapshot.EnvironmentThreadState.makenow usesStream.groupedWithinto group items into batches (default size 64, window 16ms) before applying them, so a burst of events results in a single state publication.eventBatchSizeoption onEnvironmentThreadStateOptions.Macroscope summarized 783fd02.