perf(client): keep latestTurn and checkpoint refs stable while streaming - #227
Open
leoisadev1 wants to merge 2 commits into
Open
perf(client): keep latestTurn and checkpoint refs stable while streaming#227leoisadev1 wants to merge 2 commits into
leoisadev1 wants to merge 2 commits into
Conversation
Assistant text deltas rebuilt latestTurn as a new object on every event, even when every field matched. Selectors and memos keyed on that record then reran for no reason. Checkpoints already reused the input array when nothing needed rebinding. reuseLatestTurn now returns the previous object when identity, state, timestamps, assistant message id, and proposed-plan ids match. The same-turn recompute also keeps an existing sourceProposedPlan so Akeru plan links are not dropped. Tests cover a streaming delta that must keep both references and the first assistant message that must replace them. Adapted from T3 Code pingdotgg#9145. Grok 4.6 High in Grok Build via Orca.
|
The latest updates on your projects. Learn more about Vercel for GitHub. 1 Skipped Deployment
|
github-actions
Bot
added
vouch:trusted
Greptile SummaryThis update improves reducer reference stability during assistant streaming while retaining current same-turn metadata. Request-message, responding-bot, proposed-plan, and checkpoint identities are preserved and compared so consumers receive accurate latest-turn state. Confidence Score: 5/5Safe to merge. No outstanding findings remain. The previously reported stale-turn-metadata issue is fully addressed: request-message and responding-bot identities are now retained for the active turn and included in the latest-turn equality comparison. Reviews (2): Last reviewed commit: "fix(client): keep request and responding..." | Re-trigger Greptile |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
reuseLatestTurn compared only a subset of latestTurn. Same-turn session and streaming updates rebuilt a candidate without requestMessageId or respondingBotId, then kept the old object anyway. Copy those identities onto the candidate and compare them so selectors cannot see a stale bot or request id. Grok 4.6 High in Grok Build via Orca.
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.
Problem
Every assistant streaming delta rebuilt
latestTurnas a new object even when nothing in it changed. Selectors and memos keyed on that record reran for no reason during a reply.Adaptation
reuseLatestTurnreturns the previous object when turn identity, state, timestamps, assistant message id, request/responding-bot ids, and proposed-plan ids all match.thread.message-sentandthread.session-setgo through that helper. Checkpoints already kept the input array when no rebind was needed. Same-turn recomputes also keep an existingsourceProposedPlanso Akeru plan links are not dropped.Messages still get a new array on each delta, as they must.
Upstream credits
Reviewed adaptation of T3 Code #9145.
Scope
Client reducer reference stability only. Server replay, subscription lifetime, config bootstrap, and static caching are separate PRs.
Verification
Head
e3f241faad09c6547413bcc1322cf822335ed559onleoisadev1/t3-port-thread-ref-stability. Isolated home/tmp/akeru-227-verify.QyRxU8(populated fixture plus a second bot, Crew group, bound checkpoints, and later live Mastra turns). Web on this branch only. #216 stills were not reused.vp test run packages/client-runtime/src/state/threadReducer.test.ts: 36 passed, including streaming-reference and first-bind casesvp run --filter @t3tools/client-runtime typecheckpassedIntegrated web pass on BotThreadLanding and GroupThreadLanding:
/bots/ui-scoutkept both user lines and the fallback reply. No re-pair.What this did not prove
mastra-turn-*inerrorwith no newcheckpoint_ref.ui-thread-0andui-group-thread-0return boundcheckpointRef+README.mdfiles, and the live threads still carry the seeded checkpoint row. Bot/group landing does not mount DiffPanel. Ctrl+D did nothing there.Group reload crash (not this diff)
A full reload of
/groups/ui-crewhit "This view failed to load":Rendered more hooks than during the previous renderfromuseReplyPlaybackThreadinGroupThreadLanding. Retry restored the chat.useReplyPlaybackThreadruns afterif (!group) return null, so the first paint with a missing group uses fewer hooks than the next one. This PR only changesthreadReducer.ts. Scout reload did not hit it.vp run dev --sharefailed withtailscale servepermission denied, so there is no tailnet pairing URL from this run.Grok 4.6 High in Grok Build via Orca.