Lesson 05 — isStreaming stuck on abort during a tool call

1. What stays broken after stop()

A user calls stop() from useAgentChat (or a callable that calls abortAllRequests()) while a tool call is running. Everything you'd expect to happen, does: the WebSocket cancel frame goes out, the in-flight stream is closed, the AI SDK updates its status. But one thing doesn't happen: isStreaming stays true.

The reporter's tools come from an MCP server, which matters: MCP tools execute server-side, inside the chat turn's streamText loop, not via the client onToolCall callback. The obvious hypothesis is that the server, blocked awaiting a slow MCP tool, never signals that the stream ended — so the client never learns the turn is over.

That hypothesis is wrong, and this lesson's main job is to show why it's wrong and where the bug actually lives. The discipline here is: when a symptom points at one layer (server), prove or disprove that layer before fixing anything. We disprove it with a reproduction, then follow the evidence to the client.

2. How isStreaming is built

isStreaming is not stored state. It is derived on every render from three independent signals.

The derivation, from packages/ai-chat/src/react.tsx:

const hasPendingClientToolCalls = (() => {
  const hasOnToolCall = !!onToolCall;
  if (!hasOnToolCall && !tools) return false;
  if (!lastAssistantMessage) return false;
  for (const part of lastAssistantMessage.parts) {
    if (!isToolUIPart(part)) continue;
    if (part.state !== "input-available") continue;
    ...
    if (hasOnToolCall || tools?.[toolName]?.execute) return true;
  }
  return false;
})();

const effectiveIsServerStreaming = isServerStreaming || hasPendingClientToolCalls;
const isStreaming = status === "streaming" || effectiveIsServerStreaming;

hasPendingClientToolCalls was added by issue #1365 to plug a gap: when a server-side turn emits a tool call and then closes its stream, status drops to "ready" even though the async onToolCall is still working. Without this flag, there would be no way to show a loading indicator during that gap. The fix is sound for the normal completion case. It has a hole in the abort case.

3. The happy path

Here is what happens when a tool call completes normally:

sequenceDiagram
  participant U as User
  participant R as React
  participant S as Server

  U->>R: sendMessage("find me a restaurant")
  Note over R: status="streaming", isStreaming=true
  S-->>R: tool-input-start, tool-input-delta
  S-->>R: tool-input-available (done: false)
  S-->>R: done: true
  Note over R: status="ready"
  Note over R: hasPendingClientToolCalls=true
  Note over R: isStreaming=true ← correct, tool still running
  R->>R: onToolCall fires async
  R->>R: addToolOutput called
  Note over R: tool part → output-available
  Note over R: hasPendingClientToolCalls=false
  Note over R: isStreaming=false ← clean
            

The tool part transitions from input-available to output-available when addToolOutput is called. That transition is what makes hasPendingClientToolCalls drop to false.

4. Where abort breaks the state machine

Now consider what happens when stop() is called while the tool is still running:

sequenceDiagram
  participant U as User
  participant R as React
  participant S as Server (MCP tool)

  U->>R: sendMessage("look up the order")
  S-->>R: tool-input-available (searchDatabase, done: false)
  Note over R: status="streaming", isStreaming=true
  Note over S: MCP tool running server-side…
  U->>R: stop()
  R->>S: CF_AGENT_CHAT_REQUEST_CANCEL
  S-->>R: done: true (abort path)
  Note over R: status="ready"
  Note over R: isServerStreaming=false
  Note over R: searchDatabase part still input-available
  Note over R: hasPendingClientToolCalls=true ← STUCK
  Note over R,S: isStreaming stays true forever
            

The call to stop() goes through stopWithToolContinuationAbort:

const stopWithToolContinuationAbort: typeof stop = useCallback(async () => {
  try {
    customTransport.cancelActiveServerTurn();   // sends cancel frame
    await stop();                               // AI SDK stop
  } finally {
    customTransport.abortActiveToolContinuation(); // abort continuation stream
  }
}, [stop, customTransport]);

After this runs: the cancel frame is sent, the server replies with done: true, status returns to "ready", and isServerStreaming clears. But the searchDatabase tool part is still in input-available — the server never sent tool-output-available because the turn was aborted before the tool finished. hasPendingClientToolCalls reads that state on the next render and returns true.

The only things that transition a tool part out of input-available are a tool-output-available from the server, or a client addToolOutput. Neither fires on abort. For an MCP tool the client has no addToolOutput to call anyway — it was the server's tool. The part is frozen, and the flag is pinned.

5. Disproving the server hypothesis

MCP tools execute server-side. While the tool runs, streamText is suspended and the server's read loop in _streamSSEReply (index.ts:3858) is parked on await reader.read() (index.ts:3893). The worry is that abort can't break that suspension, so done: true never goes out.

But the abort signal is wired in two independent places. The read loop checks abortSignal?.aborted each iteration, AND an abort listener cancels the reader directly:

// index.ts:3879
if (abortSignal && !abortSignal.aborted) {
  abortSignal.addEventListener("abort", () => {
    reader.cancel().catch(() => {});   // unblocks the parked read()
  }, { once: true });
}

Per the WHATWG Streams spec, reader.cancel() resolves a pending read() with { done: true } — it does not wait for the suspended source (the tool) to produce anything. The loop sees done, sees abortSignal.aborted, breaks, and the post-loop branch broadcasts the terminal frame:

// index.ts:4239 — runs after the loop breaks on abort
if (!streamCompleted.value) {
  this._completeStream(streamId);
  streamCompleted.value = true;
  this._broadcastChatMessage({ body: "", done: true, id, type: ... });
  return { status: "aborted" };
}

One detail that makes the safety net necessary: the MCP tool wrapper's execute ignores the AI SDK abortSignal (mcp/client.ts:1499), so the in-flight MCP request is not cancelled — it runs to completion and its result is discarded. Stream termination does not depend on the tool, precisely because reader.cancel() is independent of it.

So the server emits done: true, the client's status returns to "ready", and isServerStreaming clears. Two of the three signals are correctly false. The stuck flag is the third one — hasPendingClientToolCalls — which the next section showed never resets. The MCP tool part is frozen in input-available, and line 2217 counts it whenever the app also defines onToolCall or tools.

6. Design options for the fix

Option A: stopped ref in useAgentChat

Add a userStoppedRef = useRef(false). Set it to true in stopWithToolContinuationAbort. Clear it at the start of the next sendMessage. In the hasPendingClientToolCalls derivation, add a short-circuit:

if (userStoppedRef.current) return false;

Minimal. No message state changes. The tool part stays in input-available in the message list, which may or may not be desirable for UIs that render tool state.

Option B: call addToolResult with a sentinel error

In stopWithToolContinuationAbort, after stopping, find every input-available tool part in the last assistant message and call addToolResult with an error sentinel:

for (const part of lastMessage.parts) {
  if (isToolUIPart(part) && part.state === "input-available") {
    addToolResult({
      toolCallId: part.toolCallId,
      result: { error: "Aborted" }
    });
  }
}

Self-heals the message state. Any UI rendering tool output will see a clean terminal state. More invasive — changes what the user's message history looks like after a stop.

Option C: check AI SDK abort state

If the AI SDK exposes a stable way to check that a stop has been called (e.g., via the status field or a dedicated flag), use it in the derivation. Worth checking whether status === "submitted" or any short-lived intermediate state after stop() could be used, but this requires inspecting the AI SDK internals and is likely fragile.

7. Two reproductions, two layers

The investigation produced two tests, one per layer. The pairing is the point: the passing server test rules out the server, and the failing client test localises the defect.

Server (passes): the server is not the bug

tests/cancel-request.test.ts → "Cancel during server-side tool execution". A new test agent emits a tool call then holds the stream open (a suspended MCP tool). Cancelling mid-tool yields a done: true frame and no tool-output-available. It passes today — evidence the server terminates correctly.

Client (fails): the MCP over-count

react-tests/use-agent-chat.test.tsx → "isStreaming on abort during a server-side (MCP) tool call". It seeds a searchDatabase tool part (server-run) in input-available, defines onToolCall for a different client tool (getLocation), and asserts isStreaming goes false after stop(). It fails: the MCP part is counted by line 2217 even though onToolCall never handles it.

// onToolCall owns getLocation, NOT searchDatabase (server's job)
// seed searchDatabase as input-available
// isStreaming === true   ← correct while server runs it
// await stop()
// isStreaming === false   ← currently FAILS

The issue #1365 test at use-agent-chat.test.tsx:4576 remains the guard for the happy path (flag stays true while a tool genuinely runs), so any fix must keep it green.

8. Self check