AI SDK v5 Alpha 15 - Stop function (abort signal) with resumable-stream

[arthberman]

Description

Description:
I'm encountering an issue when using the stop function (via abortSignal) in combination with resumable-stream in AI SDK v5 Alpha 15. When I attempt to abort a streaming response, I receive the following error:

[ResponseAborted: ]
⨯ unhandledRejection: [ResponseAborted: ]
⨯ unhandledRejection: [ResponseAborted: ]

This seems to be an unhandled rejection related to the abort signal, but it's unclear if this is expected behavior or a bug.

---

Reproduction Steps:

1. Set up a streaming request using streamText with an abortSignal.
2. Use a resumable stream (see code below).
3. Trigger the abort signal during the stream.

Code Example (extract from route.ts):

const result = streamText({
  _internal: {
    generateId: () => crypto.randomUUID(),
  },
  model: provider.languageModel(requestBody.data.modelId),
  messages: convertToModelMessages(messages),
  system: ChatSystemPrompt(),
  experimental_transform: smoothStream(),
  abortSignal: request.signal,
  onError: (error) => {
    console.error(error);
  },
  providerOptions: {
    bedrock: {
      reasoning_config: {
        type: "enabled",
        budget_tokens: 2048,
      },
    },
    google: {
      thinkingConfig: {
        includeThoughts: true,
        thinkingBudget: 2048,
      },
    },
    anthropic: {
      thinking: { type: "enabled", budgetTokens: 12000 },
    },
  },
  experimental_telemetry: {
    isEnabled: true,
  },
});

---

Additional Information:

• The error appears as soon as the abort signal is triggered.
• The error is not caught by the onError handler (both handlers from streamText and .toUIMessageStreamResponse).

---

Let me know if you need any more details or a minimal reproduction repository. Thank you!

AI SDK Version

-ai: 5.0.0-alpha.15

[chrisdadev13]

+1

[arthberman]

To add some additional context:
When we set abortSignal in streamText, it appears that resumable-stream does not properly handle the case when the stream is aborted—it keeps attempting to resume the stream after the abort.
Additionally, we need a way to detect and control when the stream is aborted so we can save the output tokens generated up to that point in the database. With the current configuration, this does not seem possible.

[berksafran-wt]

+1

I am using not alpha version and I could not find a way to pass abortSignal from frontend to backend side. How did you pass it in the request?

[wingleeio]

Getting this as well

@berksafran-wt

I believe if you are using useChat the abortSignal should already be applied to the fetch call