fix(app): resolve message identity by id when creation time shifts - #41429
Open
leepokai wants to merge 1 commit into
Open
fix(app): resolve message identity by id when creation time shifts#41429leepokai wants to merge 1 commit into
leepokai wants to merge 1 commit into
Conversation
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
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.
Issue for this PR
Closes #41428
Type of change
What does this PR do?
#41001 (9113255) started ordering stored messages by creation time and switched message lookups to an exact match on
time.created + id. But the same message can legitimately appear with two differenttime.createdvalues: the optimistic user message is stamped with the client'sDate.now()while the server persists the same message id with its own clock. Any skew makes the keys differ, so themessage.updatedhandler misses the existing row and splices the server copy in as a second row with the same id. The stale row sticks around until a full refetch: the fork dialog lists the prompt twice,message.removeddeletes only the first match and leaves a ghost row, andmergeOptimisticPagenever runs its confirmed/observed bookkeeping for the time-shifted item.The fix keeps the creation-time ordering from #41001 but treats the id as the message's identity when the exact key misses: the
message.updatedhandlers (server-session.ts, global-syncevent-reducer.ts) drop any same-id row before inserting the update at its sorted position, and bothmergeOptimisticPageimplementations count a same-id row as found so no duplicate is inserted and confirmation fires. Per-session arrays are small, so the extra linear scan only runs on the rare key miss.How did you verify your code works?
From
packages/app:message.removedafter a time-shifted update, refresh-time optimistic confirmation, and the same-id case in bothmergeOptimisticPages. Without the fix they fail (bun test --conditions=solid --preload ./happydom.ts src/context/server-session.test.ts src/context/global-sync/event-reducer.test.ts src/context/sync-optimistic.test.ts→ 96 pass, 6 fail); with it all pass (102 pass, 0 fail).bun test --conditions=solid --preload ./happydom.ts src/context→ 316 pass, 0 fail.bun run test:unit→ 724 pass, 0 fail.bun run typecheck→ clean.test:browser/ Playwright e2e were not run locally; this is a state-store change covered by the unit tests above.Screenshots / recordings
N/A — state-store fix, unit-tested.
Checklist