fix(vscode-ide-companion): preserve split stream message ordering#3450
Merged
Conversation
Contributor
Code Coverage Summary
CLI Package - Full Text ReportCore Package - Full Text ReportFor detailed HTML reports, please see the 'coverage-reports-22.x-ubuntu-latest' artifact from the main CI run. |
wenshao
approved these changes
Apr 19, 2026
wenshao
left a comment
Collaborator
There was a problem hiding this comment.
No issues found. LGTM! ✅ — gpt-5.4 via Qwen Code /review
qqqys
added a commit
that referenced
this pull request
Apr 24, 2026
…ng (#3573) #3450 pinned every assistant/thinking segment in a streamed turn to the same turn-start timestamp so a later user message could not be sorted between two segments of the previous turn (#3273). That fix turned out to conflict with the tool-call timeline: tool calls carry their own arrival timestamp, which is strictly greater than the turn-start timestamp, so after #3450 every tool call sorted AFTER both assistant segments instead of between them — the exact 'tool call jumped to the end' ordering bug users are now reporting. The two bugs pull the sort key in opposite directions and cannot both be satisfied by a single timestamp strategy. Roll #3450 back byte-for- byte on useMessageHandling.ts so the tool-call ordering regression is fixed immediately; replace the test file with two focused cases that pin the conflicting invariants so the next fix (likely a monotonic sequence key shared across messages and tool calls) has a clear target: - tool-call interleave test (passes today): a tool call that arrives between two assistant segments must sort strictly between them. - #3273 regression test (it.fails today): all assistant segments of one turn must sort before a user message sent during the turn. Flipped to a normal it() once the proper fix lands. Refs: #3273, #3450 Co-authored-by: Qwen-Coder <noreply@qwenlm.ai>
xaelistic
pushed a commit
to xaelistic/qwen-code
that referenced
this pull request
Jun 7, 2026
xaelistic
pushed a commit
to xaelistic/qwen-code
that referenced
this pull request
Jun 7, 2026
… sharing (QwenLM#3573) QwenLM#3450 pinned every assistant/thinking segment in a streamed turn to the same turn-start timestamp so a later user message could not be sorted between two segments of the previous turn (QwenLM#3273). That fix turned out to conflict with the tool-call timeline: tool calls carry their own arrival timestamp, which is strictly greater than the turn-start timestamp, so after QwenLM#3450 every tool call sorted AFTER both assistant segments instead of between them — the exact 'tool call jumped to the end' ordering bug users are now reporting. The two bugs pull the sort key in opposite directions and cannot both be satisfied by a single timestamp strategy. Roll QwenLM#3450 back byte-for- byte on useMessageHandling.ts so the tool-call ordering regression is fixed immediately; replace the test file with two focused cases that pin the conflicting invariants so the next fix (likely a monotonic sequence key shared across messages and tool calls) has a clear target: - tool-call interleave test (passes today): a tool call that arrives between two assistant segments must sort strictly between them. - QwenLM#3273 regression test (it.fails today): all assistant segments of one turn must sort before a user message sent during the turn. Flipped to a normal it() once the proper fix lands. Refs: QwenLM#3273, QwenLM#3450 Co-authored-by: Qwen-Coder <noreply@qwenlm.ai>
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
2 participants
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.
TLDR
Preserve a single stable timestamp for all assistant/thinking segments within the same streamed turn so tool-call / plan / permission splits cannot reorder the chat timeline.
Screenshots / Video Demo
N/A — this is a streaming timeline ordering fix in the VS Code companion. The change is covered by a focused regression test and manual chat-flow verification.
Dive Deeper
The webview currently merges regular messages and tool calls, then sorts them by
timestamp.startStreaming()uses the stream's original timestamp for the first assistant placeholder, but afterbreakAssistantSegment()a laterappendStreamChunk()usedDate.now()when it had to create a new assistant placeholder. That meant one assistant reply could end up with multiple timestamps, so a later user message could sort between the earlier and later assistant segments.This change keeps one stable timestamp for the active stream and reuses it whenever a split assistant/thinking segment needs a fresh placeholder. Existing timeline sorting stays unchanged; we only fix the timestamps so split segments retain their original turn ordering.
Reviewer Test Plan
packages/vscode-ide-companion, runnpm run build.npx vitest run src/webview/hooks/message/useMessageHandling.test.tsx src/webview/hooks/useWebViewMessages.test.tsx.Testing Matrix
Linked issues / bugs
Resolves #3273