fix (core): consume stream on abort

[iteratetograceness]

Addresses #5459

This PR ensures that the consumeStream method on streamText does not throw unhandled errors.

NOTE: This is an edge case that occurs when an abortSignal is passed to streamText; the aborted signal propagates to consumeStream as a ResponseAborted error but we were not catching this error. This then triggered a network error, caught by the useChat hook (setting the hook status to error).

[lgrammel]

Needs a changeset.

[lgrammel]

How does this affect the useChat UI parts?

[iteratetograceness]

How does this affect the useChat UI parts?

Before this change, because result.consumeStream would throw an unhandled response aborted error, and useChat would update status to error (disabling sending of subsequent messages)!

More details here

[lgrammel]

How does this affect the useChat UI parts?

Before this change, because result.consumeStream would throw an unhandled response aborted error, and useChat would update status to error (disabling sending of subsequent messages)!

More details here

So consume stream would break an ongoing response? (asking because at that point consume stream should run async and separately of the function)

[iteratetograceness]

So consume stream would break an ongoing response? (asking because at that point consume stream should run async and separately of the function)

Ah aligned, consumeStream = independent from function! I misspoke (corrected above), and the unhandled error does/should not directly impact useChat.

Yesterday, while repro-ing, the unhandled error from consumeStream seemed to put the server in a funky state - verifying now but upon the subsequent user message, useChat's status is stuck on submitted

[lgrammel]

The consumeStream resilience is very good regardless (and maybe it should swallow all errors or have an error callback to not break any server).

[iteratetograceness]

@lgrammel heard!

Also, I'm not crazy, I did see status set to error when we do not properly swallow abort errors from consumeStream! See video:

CleanShot.2025-04-02.at.11.49.17.mp4

If stop fires while long response is streaming, consumeStream's unhandled abort error seems to bubble up in triggerRequest's catch as a network error!

[lgrammel]

@iteratetograceness that is very interesting - do you know what happens (on the network level)? is the next js server forwarding the error through the stream somehow?

other server might behave differently

[iteratetograceness]

@iteratetograceness that is very interesting - do you know what happens (on the network level)? is the next js server forwarding the error through the stream somehow?

other server might behave differently

I don't think this is Next.js server specific! I believe the unhandled network error is bubbling up to the nearest error handler in the event loop (which prior to these changes would be triggerRequest's catch)

[iteratetograceness]

@lgrammel oh but I am seeing a slightly different edge case now! If a subsequent message isn't sent after the stopping, onFinish does not trigger. Any inklings on what causes this? I'm gonna take a closer look at the stream logic in stream-text.ts

[iteratetograceness]

@lgrammel tldr, when the abort signal is passed into the streamText, consumeStream does not trigger onFinish (the onFinish callback is only called as a side effect of subsequent messages' flushes)

im stepping away for a bit but will come back to dig deeper and flesh out the appropriate solution (e.g. maybe something along the lines of adding new user-cancellation finishReason and adding logic for this case)

[lgrammel]

prefer options object

[ItayElgazar]

is it released already? I am still experiencing the bug, even after upgrading to v4.3.9

[iteratetograceness]

@ItayElgazar this fix has already been released. I recommend opening a new discussion/issue with more context or minimal repro steps!