Socket close mid-stream is treated as a completed response #2013

ai slop but still true:

Describe the bug

When the WebSocket closes mid-stream, WebSocketChatTransport ends the response stream with controller.close() instead of controller.error(...). The AI SDK treats that as a normal completion, so a dropped connection is indistinguishable from a finished answer.

// agents@0.20.1 dist/chat/react.js:255-257
const onClose = () => {
  finish(() => controller.close(), false, false);
};

The same pattern appears again at :473. Compare :245, where an explicit error frame correctly calls controller.error(new Error(data.body || "Stream error")).

The user is left with a silently truncated assistant message: no error state, no retry affordance, and nothing marking the response as incomplete. isLoading clears as if the turn succeeded.

To Reproduce

Steps to reproduce the behavior:

1. Start a chat turn with useAgentChat that streams a long assistant response.
2. While the response is still streaming, drop the WebSocket (kill the network, or close the socket from devtools).
3. Observe the partial assistant message.
4. See that the stream resolves cleanly — no onError, no error state, and the truncated message is presented as a completed answer.

Expected behavior

A socket close during an in-flight stream should surface as an error, the same way an explicit error frame does, so the UI can show that the response was interrupted and offer a retry.

Screenshots

N/A.

Version:

agents@0.20.1. Also present in 0.19.0.

Additional context

We patch this locally to finish(() => controller.error(new Error("Chat connection interrupted")), false, false), which restores the expected error state.

This is distinct from #1898, which covers terminal error: true frames in the React observer path. This one is the transport's socket-close handler, where no frame arrives at all.