Summary

reportAutoModeRouting installs an onDidRoute listener that pushes Auto explainability parts (ChatResponseAutoModeResolutionPart) into the turn's ChatResponseStream when routing starts and resolves. Routing resolves asynchronously (POST /auto), so when the user cancels the turn mid-route, VS Code core closes the response stream before the listener fires. The subsequent stream.push(...) throws Error: Response stream has been closed, which escapes resolveAutoModeEndpoint and reaches the unhandled-error telemetry pipeline. It affected 108 users on GitHub.copilot-chat 0.69.0.

Fixes #341067
Recommended reviewer: @spurwaha

Culprit Commit

Code Flow

sequenceDiagram
    participant User as User
    participant Handler as chatParticipants handler
    participant Service as AutomodeService
    participant Listener as onDidRoute listener
    participant Stream as ChatResponseStream

    User->>Handler: start Auto turn
    Handler->>Service: resolveAutoModeEndpoint(request)
    Note over Service: await POST /auto<br/>(async routing)
    User->>Stream: cancel turn
    Note over Stream: ⚠️ Root cause:<br/>core closes the stream on cancel
    Service->>Listener: fire onDidRoute (started / resolved)
    Listener->>Stream: stream.push(ChatResponseAutoModeResolutionPart)
    Note over Stream: 💥 Error thrown:<br/>Response stream has been closed

Affected Files

Repro Steps

1. Enable Auto model in Copilot Chat.
2. Start a chat turn on a cold conversation so routing must call POST /auto (no cached endpoint).
3. Cancel the turn (Escape / stop button) while the routing request is still in flight.
4. Core closes the response stream; when the awaited routing call resolves, the onDidRoute listener calls stream.push(...) on the closed stream and Error: Response stream has been closed is thrown. Because routing latency is network-bound, the race is easiest to hit on slow connections or by cancelling immediately after submitting.

How the Fix Works

Chosen approach — automodeService.ts → reportAutoModeRouting(): thread the turn's CancellationToken into the function and guard both stream.push(...) calls with !token.isCancellationRequested. The chat participant handler (chatParticipants.ts:211) already receives the request token and now forwards it. Once the turn is cancelled, core has closed the stream, so the explainability part is both unsafe to push and moot (there is no live turn to annotate) — skipping the push is the correct behavior, not merely error avoidance.

This is a use-after-close lifecycle race where the producer that closes the stream is VS Code core's chat request plumbing, outside the extension's reach — the extension cannot reorder or block core's stream teardown. The guard therefore lives at the consumer (the listener), which is the justified place for an external/untrusted-boundary lifecycle fix. The fix sits at the real bypass (the unconditional push onto a possibly-closed stream), not at a generic catch-all.

Why this fix: after this change, the listener at automodeService.ts:110 and :114 cannot call stream.push(...) once the turn's token is cancelled, which is exactly when core has closed the stream — so the Response stream has been closed throw on that path is no longer reachable.

Alternatives considered:

• Wrap the stream.push(...) calls in try/catch — rejected: swallows the error, hides any future unrelated stream failures, and does not express the real invariant (don't push to a cancelled turn).
• Have ChatResponseStreamImpl silently drop pushes after close — rejected: changes shared stream semantics for every caller to paper over one producer's post-cancel push.

Lifecycle pattern: use-after-dispose (stream closed by cancellation, listener fires afterward).
Producer site: VS Code core chat request plumbing closes the ChatResponseStream on cancellation — not reachable from extensions/copilot. Consumer-side guard justification: the only in-repo signal the extension has for this teardown is the request CancellationToken, so gating the push on that token is the closest-to-producer fix available to the extension.

Recommended Owner

@spurwaha — author of the culprit commit d7132ac6c9b5 (PR #336757), which introduced the stream pushes in reportAutoModeRouting. Active in microsoft/vscode within the last 90 days and lands changes in core src/vs (write access).