[KongchangAI]
· 1 min read· 990 words

AI SDK Adds 'Interrupted' Finish State: Upgraded Streaming Output Handling

AI SDK Adds 'Interrupted' Finish State: Upgraded Streaming Output Handling

AI SDK xAI adapter 5.0.28 adds an interrupted finish state, unifying streaming interruption semantics across 10+ providers.

AI SDK's @ai-sdk/xai releases patch 5.0.28. The core change is a new `interrupted` finish reason, which signals that an upstream model stream ended cleanly without a provider completion signal: partial output is preserved and no error is thrown. Although shipped under the xAI package, the change actually covers 10+ providers including OpenAI, Anthropic, Google, Bedrock, Cohere, DeepSeek, Groq, Mistral, Moonshot, and Perplexity—a unified semantic adjustment at the provider abstraction layer. The team issues a compatibility notice requiring apps to explicitly handle interrupted in switch statements, mapping tables, and validations; meanwhile, genuine provider, parse, and transport errors now correctly report error instead of being lumped into other, which may raise error-rate statistics. The article recommends checking all finish reason consumption points, distinguishing continuable vs. retry scenarios, and upgrading related dependencies in sync.

rss source: @ai-sdk/xai@5.0.28

The AI SDK's xAI adapter package has released patch version 5.0.28. On the surface it looks like a routine dependency update, but the patch change touches on an issue that every streaming caller must confront: what finish reason should be reported when an upstream model stream ends normally without a provider completion signal.

A Long-Ignored Gray Area

Streaming output is the mainstream calling pattern for large model applications today, but a stream "ending" and a stream "completing" are two different things. Completion means the provider explicitly sent a termination signal, whereas ending may simply mean the connection dropped, the message was truncated, or the upstream service closed early. Previously, such cases in AI SDK would fall back to other, or simply not emit a finish part at all.

Version 5.0.28 formally models this state as interrupted: it preserves the partial output already produced, while not throwing an error because of the "interruption" itself. This distinction is critical—interruption is not the same as failure; it could be a user-initiated cancellation or a truncation that needs retrying.

Coverage Far Beyond xAI

Although the version number sits under @ai-sdk/xai, the impact of this change spans OpenAI (Chat, Responses, Completions), Anthropic, Google (Generate Content and Interactions), Alibaba, Amazon Bedrock Converse, Cohere, DeepSeekAd, Groq, Hugging Face Responses, Mistral Chat, Moonshot AI, Open Responses, Perplexity, and xAI Responses. It also covers truncation in Anthropic follow-up messages and Google's automatic continuation scenarios.

In other words, this is a unified semantic adjustment at the provider abstraction layer; shipping it in the xAI package is more a result of release scheduling than a scope limitation.


finish reason is an enumerated field returned by AI SDK after each generation ends, used to tell callers why this generation terminated. Common values include stop (the model ended naturally), length (token limit reached), content-filter (blocked by safety policy), tool-calls (the model requested a tool call), error (an error occurred), and other (an unclassifiable unknown reason). In streaming calls, this field is usually carried by the final finish part; if the upstream never sends a termination signal, callers cannot obtain a reliable finish part. The introduction of interrupted is precisely meant to fill this gap in the enum: it indicates that the stream has ended but no provider completion signal was received—a distinct state of "ended normally but the result may be incomplete," rather than an error.

The provider abstraction layer refers to AI SDK's unified wrapper over multiple model vendors' APIs. Each vendor's streaming protocol, termination markers, and error code formats differ significantly; the SDK defines a unified interface via @ai-sdk/provider, and each adapter package (such as @ai-sdk/xai, @ai-sdk/openai) translates the vendor's raw events into this unified semantics. Therefore, once the finish reason values are adjusted, all adapter packages and all downstream applications are affected simultaneously.

Compatibility Warning: switch Statements Will Silently Miss the Case

The official patch notes specifically include a Compatibility notice, which is uncommon for a patch release. The core message is: applications that previously relied on finishReason for branching logic need to add an interrupted branch in switch statements, mapping tables, and custom validations.

The recommended approach is to explicitly check finishReason === 'interrupted' to identify incomplete responses. One point to emphasize: interruption itself does not trigger the error handling path—if your code uses try/catch as a fallback, such cases will not be caught and can only be detected via finish reason.

The Boundary Between error and other Has Been Redrawn

The change also tightens the semantics of two categories of states:

  • Explicit unknown completion reasons still map to other;
  • Genuine provider errors, parse errors, and transport errors retain the error path—some error paths previously classified as other will now correctly report error.

This has a direct impact on logging and monitoring. Anomalous traffic previously lumped into other will be separated out, and error rate statistics may therefore rise—but this is a correction, not a regression. The OpenAI compatibility layer remains unchanged, indicating that the team made trade-offs regarding backward compatibility.

Three Practical Recommendations for the Application Layer

First, check all finish reason consumption points. Beyond the main flow, don't forget edge paths like telemetry reporting, A/B experiment grouping, and content moderation—these often use string matching rather than enums.

Second, distinguish "continuable" from "needs retry." Google's automatic continuation and Anthropic's multi-message truncation are continuable scenarios, where you can concatenate subsequent content based on the preserved partial output; pure transport interruptions are better suited to retries.

Third, upgrade dependencies in sync. This release also updates @ai-sdk/provider to 4.0.32 and @ai-sdk/provider-utils to 5.0.66; mixing old versions across packages may lead to inconsistent finish part parsing.


Continuation vs. retry depends on understanding the interruption context. The premise for continuation is that the content already produced upstream is semantically continuous and concatenable—for example, Google Generate Content's automatic continuation triggered by output length limits, or truncation in Anthropic follow-up messages. These preserve complete message boundaries and can carry existing content into the next request to continue generation. Retry is suitable for transport-layer interruptions, where the context may be incomplete or duplicated, and replaying the request directly is safer. In practice, it's recommended to record metadata for interruption events (such as number of tokens generated, whether a finish part was ever received, and at which chunk the interruption occurred) to decide whether to take the continuation or retry path, avoiding storing half-finished content as a complete result.

Summary

5.0.28 is a change with a small version number but a large semantic surface. It turns "silent truncation" in streaming output—a long-ambiguous state—into a programmable first-class citizen, at the cost of requiring all downstream applications to actively adapt. For teams building production-grade AI applications, this kind of change at the underlying abstraction layer deserves a spot on the regression testing checklist, rather than waiting until half-finished answers appear in production.

For related discussion, refer to the original release notes on the GitHub Releases page.

#AI SDK#interrupted finish reason#streaming output#provider abstraction#@ai-sdk/xai#compatibility
Share:

Related articles