fix(vscode): prevent race conditions in prompt cancellation and streaming#2374
Merged
Conversation
…ming - Add pendingPromptCompletion tracking to ensure new prompts wait for previous prompt's tool results before reading chat history - Add requestId correlation between streamStart/streamEnd to detect and discard stale events from cancelled requests - Guard against duplicate streamEnd messages - Preserve isWaitingForResponse during cancel to prevent auto-submit This fixes malformed history issues in VS Code extension where rapid prompt cancellation and resubmission caused tool_call → user_query → tool_result ordering instead of the correct sequence. Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>
Add `forRequestId` parameter to `sendStreamEnd()` to detect and ignore stale calls when a newer request has taken over shared state. This prevents stale handleSendMessage invocations from emitting streamEnd events tagged with the wrong request ID. Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>
Contributor
📋 Review SummaryThis PR addresses critical race conditions in the VSCode extension related to prompt cancellation and streaming state management. The implementation is well-thought-out with proper request scoping and state synchronization. The changes effectively prevent malformed chat history and stale event propagation, particularly on Windows where process termination is slower. 🔍 General Feedback
🎯 Specific Feedback🟡 High
🟢 Medium
🔵 Low
✅ Highlights
|
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. |
- Install AbortController before awaiting previous prompt so session/cancel during the wait targets the correct prompt - Check if cancelled after waiting for previous prompt to complete - Drop untagged streamEnd events when a tagged stream is active This prevents race conditions where a new prompt could be incorrectly cancelled or have its state cleared by stale events from a previous prompt. Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>
yiliang114
approved these changes
Mar 16, 2026
xaelistic
pushed a commit
to xaelistic/qwen-code
that referenced
this pull request
Jun 7, 2026
…nditions fix(vscode): prevent race conditions in prompt cancellation and streaming
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
3 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
Fixes race conditions in the VSCode extension that caused malformed chat history when cancelling prompts, resulting in "tool_calls must be followed by tool messages" errors.
Before
After
Dive Deeper
This PR addresses three interconnected race conditions:
1. Windows-specific history corruption (Issues #2190, #2249)
On Windows, process termination is slow. When a user cancels a prompt and immediately sends a new one, the new prompt could read chat history before the cancelled prompt's tool results were added. This resulted in malformed history:
instead of:
Fix: Added
pendingPromptCompletionpromise in Session.ts to ensure the previous prompt fully completes (including adding tool results) before the next prompt starts.2. Cancelled requests sending stale streamEnd events
When a request is cancelled and a new one starts, the old request's error handlers could still fire and send a
streamEndevent tagged with the new request's ID (becausecurrentRequestIdwas overwritten). This caused the webview to incorrectly clear streaming state for the new request.Fix: Added request-scoping to
sendStreamEnd()withforRequestIdparameter. EachhandleSendMessagecaptures its request ID locally, and stale calls are silently dropped.3. Premature UI state clearing on cancel
The cancel handler was clearing
isWaitingForResponseimmediately, creating a window where cached input could be auto-submitted before the backend finished processing the cancel.Fix: The cancel handler now only ends streaming state and adds "Interrupted" message, but leaves
isWaitingForResponseset until the extension'sstreamEndmessage arrives.Reviewer Test Plan
On Windows, the race condition is more pronounced due to slower process termination, so testing there is especially valuable.
Testing Matrix
Linked issues / bugs
Fixes #2190
Fixes #2249
🤖 Generated with Qwen Code