feat(ai): add abort reason field to stream chunks #11443
Conversation
| "warnings": [], | ||
| }, | ||
| { | ||
| "reason": [AbortError: This operation was aborted], |
There was a problem hiding this comment.
this isn't json serializable. is there way to make the reason a string?
| }), | ||
| z.strictObject({ | ||
| type: z.literal('abort'), | ||
| reason: z.unknown().optional(), |
There was a problem hiding this comment.
can this be an optional string instead to ensure that it is serializable?
There was a problem hiding this comment.
You’re right; it should be a serializable value.
There was a problem hiding this comment.
I have changed it to an optional string.
Pass through abort reason when provided in abort signals to improve debugging and user feedback. Includes updates to types, schemas, and tests to support the new field.
Add documentation for the abort part in stream protocol and include optional reason field in stream-text reference
EurFelux
force-pushed
the
feat/abort-reason
branch
from
168f376 to
1e7e061
Compare
Use getErrorMessage to serialize reason for safe JSON transmission in stream text results
Remove redundant error type check for abort reason and streamline environment variable naming for Deepseek API
…serialization" This reverts commit 7cdc0ed.
| // Use getErrorMessage to serialize reason (unknown) to string for safe JSON transmission | ||
| ...(abortSignal?.reason !== undefined | ||
| ? { reason: getErrorMessage(abortSignal.reason) } | ||
| : {}), |
There was a problem hiding this comment.
getErrorMessage seems incorrect here. Even if it constrains the functionality, would it be possible to check if abortSignal?.reason is a string and ignore it otherwise? (i.e. change the condition in 1017 such that we know that the reason is a string)
There was a problem hiding this comment.
You can’t just accept a string only. Please see https://developer.mozilla.org/en-US/docs/Web/API/AbortSignal/reason: by default, the reason field is set to a value of type DOMException, not a string. In fact, you can set it to any value using the abort function, which is why I previously designed the field’s type as unknown. Given that this is the default behavior, if we only accepted string, we would lose the reason in most use cases.
There was a problem hiding this comment.
I used getErrorMessage for the sake of code reuse, since this function can serialize errors of type unknown. I’m also aware that the fact that reason is likely an Error instance isn’t immediately obvious from its name, which might confuse maintainers who aren’t familiar with this behavior. To address this, I added a comment explaining why I’m using this function, but it seems the explanation wasn’t clear enough. I’ll provide a more precise explanation of this behavior in the comment.
2 participants
Background
Issue #11442 requests abort reason visibility on abort chunks so callers can distinguish manual vs timeout aborts when combining signals.
Summary
AbortSignal.reasontoabortchunks instreamText, and extend stream/UI chunk types and schemas to carryreason.examples/ai-core/src/stream-textdemonstrating abort reasons withAbortSignal.any(manual vs timeout).reasonfield on abort stream parts in core and UI stream protocol docs.Manual Verification
pnpm -C /Volumes/CIRCLE/dev/ai/packages/ai exec tsx /Volumes/CIRCLE/dev/ai/examples/ai-core/src/stream-text/openai-compatible-abort-reason.tsand observed abort reasons for both manual and timeout cases.Checklist
pnpm changesetin the project root)Related Issues
Fixes #11442