fix(cli): chat-stream cancel race left spinner stuck

Two leaks in processGeminiStreamEvents that #145 / #152 didn't cover:

1. case ServerGeminiEventType.UserCancelled fell through with a plain
   `break`, which only exits the switch — the for-await kept iterating
   and any toolCallRequests already collected this iteration would still
   get scheduled at the post-loop scheduleToolCalls call.

2. The post-loop scheduleToolCalls fired unconditionally. If abort
   landed in the same tick as a chunk that carried finish_reason=tool_calls
   (model emitted tool calls while user was hitting Esc), the scheduler
   added the tools in 'validating' state with an already-aborted signal.
   The per-tool aborted check at coreToolScheduler.ts:861 eventually
   marks them 'cancelled', but the React state briefly flips
   streamingState back to Responding — sticking the spinner until the
   3s forceCancelStaleToolCalls grace window catches up.

Fix: UserCancelled returns early; scheduleToolCalls is gated on
!signal.aborted. Two new tests in the Cancellation describe block
cover both arms (UserCancelled-then-toolCallRequest, and
toolCallRequest-arriving-after-abort).

51/51 useGeminiStream tests pass.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Author: Automaker

packages/cli/src/ui/hooks/useGeminiStream.test.tsx

@@ -1057,6 +1057,99 @@ describe('useGeminiStream', () => {
       // Nothing should happen because the state is not `Responding`
       expect(abortSpy).not.toHaveBeenCalled();
     });
+
+    it('should not schedule tool calls collected before a UserCancelled event', async () => {
+      // Repro for chat-stream cancel race: model emits a ToolCallRequest in
+      // one chunk, then UserCancelled in the next (e.g. user pressed Esc
+      // mid-stream and turn.ts converted the abort into a UserCancelled
+      // event). The for-await previously ran past the cancel and scheduled
+      // the queued tool call after the fact, leaving streamingState stuck.
+      mockSendMessageStream.mockReturnValue(
+        (async function* () {
+          yield {
+            type: ServerGeminiEventType.ToolCallRequest,
+            value: {
+              callId: 'call-after-cancel',
+              name: 'shell',
+              args: { command: 'echo hi' },
+            },
+          };
+          yield { type: ServerGeminiEventType.UserCancelled };
+        })(),
+      );
+
+      const { result } = renderTestHook();
+
+      await act(async () => {
+        await result.current.submitQuery('test query');
+      });
+
+      await waitFor(() => {
+        expect(mockAddItem).toHaveBeenCalledWith(
+          expect.objectContaining({
+            type: 'info',
+            text: 'User cancelled the request.',
+          }),
+          expect.any(Number),
+        );
+      });
+
+      expect(mockScheduleToolCalls).not.toHaveBeenCalled();
+      expect(result.current.streamingState).toBe(StreamingState.Idle);
+    });
+
+    it('should not schedule tool calls when the abort signal is set before the stream ends', async () => {
+      // Second arm of the same race: abort fires while the stream is
+      // still iterating, but the underlying SDK delivers the buffered
+      // ToolCallRequest chunk before honoring the abort. Stream then
+      // ends naturally (no UserCancelled event). Without the
+      // !signal.aborted guard at scheduleToolCalls, the post-loop
+      // schedule fires with an aborted signal and the React state
+      // briefly flips toolCalls into 'validating' — sticking the spinner.
+      let yieldToolCall: () => void;
+      const toolCallGate = new Promise<void>((r) => {
+        yieldToolCall = r;
+      });
+
+      mockSendMessageStream.mockReturnValue(
+        (async function* () {
+          yield { type: ServerGeminiEventType.Content, value: 'partial' };
+          await toolCallGate;
+          yield {
+            type: ServerGeminiEventType.ToolCallRequest,
+            value: {
+              callId: 'call-mid-cancel',
+              name: 'shell',
+              args: { command: 'ls' },
+            },
+          };
+        })(),
+      );
+
+      const { result } = renderTestHook();
+
+      await act(async () => {
+        result.current.submitQuery('test query');
+      });
+
+      await waitFor(() => {
+        expect(mockSendMessageStream).toHaveBeenCalledTimes(1);
+      });
+
+      // User presses Esc before the buffered tool-call chunk gets delivered.
+      act(() => {
+        result.current.cancelOngoingRequest();
+      });
+
+      // SDK now delivers the chunk that was already in flight, then ends.
+      await act(async () => {
+        yieldToolCall!();
+        await new Promise((r) => setTimeout(r, 10));
+      });
+
+      expect(mockScheduleToolCalls).not.toHaveBeenCalled();
+      expect(result.current.streamingState).toBe(StreamingState.Idle);
+    });
   });
 
   describe('Slash Command Handling', () => {

packages/cli/src/ui/hooks/useGeminiStream.ts

@@ -1220,7 +1220,13 @@ export const useGeminiStream = (
             case ServerGeminiEventType.UserCancelled:
               flushBufferedStreamEvents();
               handleUserCancelledEvent(userMessageTimestamp);
-              break;
+              // Stop processing immediately. A plain `break` only exits the
+              // switch — the for-await would continue to the next chunk and
+              // any toolCallRequests already accumulated this iteration would
+              // still get scheduled at line 1302 below. That left the spinner
+              // stuck during chat-stream cancels (chat-only freeze, distinct
+              // from the tool-execution cancel covered by #145 / #152).
+              return StreamProcessingStatus.UserCancelled;
             case ServerGeminiEventType.Error:
               flushBufferedStreamEvents();
               handleErrorEvent(event.value, userMessageTimestamp);
@@ -1299,7 +1305,16 @@ export const useGeminiStream = (
         discardBufferedStreamEvents();
         flushBufferedStreamEventsRef.current.delete(flushBufferedStreamEvents);
       }
-      if (toolCallRequests.length > 0) {
+      // Skip scheduling if the user already cancelled. The for-await may
+      // have collected toolCallRequests from a chunk that arrived in the
+      // same tick as the abort (e.g. model emits finish_reason=tool_calls
+      // right as the user presses Esc). Scheduling them post-cancel adds
+      // 'validating' tools to the React state — which flips streamingState
+      // back to Responding before the per-tool aborted check at
+      // coreToolScheduler.ts:861 can mark them 'cancelled'. The 3s
+      // forceCancelStaleToolCalls rescue eventually clears it, but the
+      // user sees a stuck spinner until then.
+      if (toolCallRequests.length > 0 && !signal.aborted) {
         scheduleToolCalls(toolCallRequests, signal);
       }
       return StreamProcessingStatus.Completed;