Uh oh!
There was an error while loading. Please reload this page.
[ai] Fix "missing text part" stream crash by repairing UI message framing - #2537
Merged
Conversation
…ming Duplicated or interleaved durable stream writes (step retry/redelivery or concurrent-worker duplication) can land a finish-step in the middle of a text part that reuses id "0", orphaning the rest. The AI SDK consumer then throws `Received text-delta for missing text part with ID "0"` and kills the turn. WorkflowChatTransport now normalizes UI message stream part framing — mirroring the consumer's per-step part-lifetime state machine — so orphaned deltas/ends get a synthesized start and replayed chunks are dropped. Well-formed streams pass through unchanged. Closes#2422 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
🦋 Changeset detectedLatest commit: 324559a The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
Contributor
Contributor
🧪 E2E Test Results❌ Some tests failed Summary
❌ Failed Tests▲ Vercel Production (3 failed)nextjs-webpack (3 failed):
Details by Category❌ ▲ Vercel Production
✅ 💻 Local Development
✅ 📦 Local Production
✅ 🐘 Local Postgres
✅ 🪟 Windows
✅ 📋 Other
❌ Some E2E test jobs failed:
Check the workflow run for details. |
Contributor
📊 Benchmark Results
workflow with no steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Next.js (Turbopack) | Express | Nitro workflow with 1 step💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express | Nitro | Next.js (Turbopack) workflow with 10 sequential steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Next.js (Turbopack) | Express | Nitro workflow with 25 sequential steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express | Next.js (Turbopack) | Nitro workflow with 50 sequential steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Nitro | Express | Next.js (Turbopack) Promise.all with 10 concurrent steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Nitro | Express | Next.js (Turbopack) Promise.all with 25 concurrent steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Next.js (Turbopack) | Express | Nitro Promise.all with 50 concurrent steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Nitro | Express | Next.js (Turbopack) Promise.race with 10 concurrent steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Nitro | Next.js (Turbopack) | Express Promise.race with 25 concurrent steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express | Nitro | Next.js (Turbopack) Promise.race with 50 concurrent steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Nitro | Express | Next.js (Turbopack) workflow with 10 sequential data payload steps (10KB)💻 Local Development
▲ Production (Vercel)
🔍 Observability: Nitro | Next.js (Turbopack) | Express workflow with 25 sequential data payload steps (10KB)💻 Local Development
▲ Production (Vercel)
🔍 Observability: Next.js (Turbopack) | Nitro | Express workflow with 50 sequential data payload steps (10KB)💻 Local Development
▲ Production (Vercel)
🔍 Observability: Nitro | Express | Next.js (Turbopack) workflow with 10 concurrent data payload steps (10KB)💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express | Nitro | Next.js (Turbopack) workflow with 25 concurrent data payload steps (10KB)💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express | Nitro | Next.js (Turbopack) workflow with 50 concurrent data payload steps (10KB)💻 Local Development
▲ Production (Vercel)
🔍 Observability: Nitro | Express | Next.js (Turbopack) Stream Benchmarks(includes TTFB metrics)workflow with stream💻 Local Development
▲ Production (Vercel)
🔍 Observability: Nitro | Next.js (Turbopack) | Express stream pipeline with 5 transform steps (1MB)💻 Local Development
▲ Production (Vercel)
🔍 Observability: Nitro | Next.js (Turbopack) | Express 10 parallel streams (1MB each)💻 Local Development
▲ Production (Vercel)
🔍 Observability: Nitro | Express | Next.js (Turbopack) fan-out fan-in 10 streams (1MB each)💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express | Nitro | Next.js (Turbopack) SummaryFastest Framework by WorldWinner determined by most benchmark wins
Fastest World by FrameworkWinner determined by most benchmark wins
Column Definitions
Worlds:
|
VaguelySerious
left a comment
MemberAuthor
There was a problem hiding this comment.
AI review: no blocking issues
| yield* repairPart('end', chunk.id, chunk, reasoning, 'reasoning-start'); | ||
| break; | ||
| default: |
MemberAuthor
There was a problem hiding this comment.
AI Review: Note
Scope question: tool-input-delta raises the same class of fatal error in the consumer (Received tool-input-delta for missing tool call with ID ...), and tool parts flow through this default branch unrepaired. The reason text/reasoning are uniquely fragile is the consumer resets activeTextParts/activeReasoningParts on finish-step while ids are reused ("0") — I confirmed against the consumer source that tool state is not reset on finish-step and tool-call ids are unique, so the step-boundary orphaning genuinely doesn't apply to tools. But the same duplication/interleave races behind this issue could still re-deliver a tool-input-start or orphan a tool-input-delta and crash a turn the same way. Worth a one-line comment here recording that tools are deliberately out of scope (and why), so the omission reads as intentional rather than missed.
MemberAuthor
There was a problem hiding this comment.
(AI) Addressed in af13a07 — added a "Scope: text and reasoning only" section to the doc comment recording that tool-input parts are deliberately out of scope and why (consumer doesn't reset tool state on finish-step; tool-call ids are unique).
| { type: 'finish' }, | ||
| ]; | ||
| describe('WorkflowChatTransport UI message stream repair (issue #2422)', () => { |
MemberAuthor
There was a problem hiding this comment.
AI Review: Note
Forward-compat: the repair mirrors an internal, undocumented behavior of processUIMessageStream (reset-on-finish-step). Under the ai: ^6 peer range a future 6.x could move that reset boundary or add a part family and silently desync the repair. Driving the real consumer here is exactly the right canary for that — but every case in this file exercises only text. The reasoning branch (and the well-formed reasoning passthrough) is asserted only structurally, so a reasoning-semantics change in a future ai wouldn't break a test. I verified locally that an interleaved reasoning stream reproduces Received reasoning-delta for missing reasoning part with ID "0" against the real consumer and that the transport repairs it to "Thinking..." with no loss — suggest adding that as a case here. I'll include it when addressing comments.
MemberAuthor
There was a problem hiding this comment.
(AI) Addressed in af13a07 — added two interleaved-reasoning cases driving the real readUIMessageStream consumer: one proving the raw stream is fatal with Received reasoning-delta for missing reasoning part with ID "0", one proving the transport repairs it to "Thinking..." with no loss. A future ai reasoning-semantics change now breaks a test.
… against real consumer - normalize-ui-message-stream: document why tool-input parts are deliberately out of scope (consumer doesn't reset tool state on finish-step; ids unique). - stream-repair test: add interleaved-reasoning cases driving the real readUIMessageStream consumer (raw stream is fatal; transport repairs to "Thinking..." with no loss), so a future ai reasoning-semantics change is caught. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Uh oh!
There was an error while loading. Please reload this page.
Signed-off-by: Peter Wielander <mittgfu@gmail.com>
Uh oh!
There was an error while loading. Please reload this page.
github-actionsBot
added a commit
that referenced
this pull request
Jun 26, 2026
…ming (#2537) Signed-off-by: Peter Wielander <mittgfu@gmail.com>
Contributor
Backport PR opened against |
pranaygp added a commit
that referenced
this pull request
Jun 26, 2026
…edrive * origin/main: (90 commits) [ai] Fix "missing text part" stream crash by repairing UI message framing (#2537) [ci] Fix release "Premature close" by bounding changelog GraphQL batch size (#2669) [ai] Drop orphan UI chunks after negative-index reconnect (#2082) Fix trace detail panel Input/Output flicker (selection-driven state machine) (#2637) [world-local] Scope untagged startup recovery to untagged runs (#2667) fix(world-postgres): defer loopback worker startup (#2657) docs: deprecate DurableAgent and WorkflowChatTransport, point to AI SDK WorkflowAgent (#2616) [web] Fix HTTP/2 in bundled server build so observability reads work (#2632) [core] Fix turbo-mode step-body writes racing run_started (#2629) fix(world-postgres): rename setup command (#2644) chore: ignore workflow swc caches (#2640) fix(ai): ignore intentional stream aborts (#2635) fix(nitro): reload steps during Vite HMR (#2572) [world] Make @workflow/world own its Zod dependency (#2622) feat(web-shared): extend cn with custom tailwind-merge class groups (#2619) [world-vercel] Enable HTTP/2 for the events API and stream writes (#2573) Remove shadow from off-screen marker indicator button (#2614) Fix discovery of dotted JS workflow imports (#2594) Version Packages (beta) (#2597) Thread occurredAt into web-shared entities (#2608) ... # Conflicts: # packages/core/src/runtime/step-executor.ts # packages/world-vercel/src/http-client.ts
2 tasks
This was referenced Jun 26, 2026
Merged
gr2m pushed a commit
to vercel/ai
that referenced
this pull request
Jun 29, 2026
…ransport (#16433) ## Summary Port of **vercel/workflow#2537** to `@ai-sdk/workflow`. A workflow run owns a single shared UI message stream, and the AI SDK's stream consumer (`processUIMessageStream`, backing `useChat`/`readUIMessageStream`) resets its active text/reasoning part maps on every `finish-step`. Multi-step turns reuse the same part id (commonly `"0"`) per step, so if a `text-start` is dropped or a `finish-step` lands mid-part, the consumer hits a `text-delta`/`text-end` for an id it has no open part for and throws: ``` Received text-delta for missing text part with ID "0". Ensure a "text-start" chunk is sent before any "text-delta" chunks. ``` …killing the whole turn. That malformed framing is reachable whenever a stream-producing step's output is duplicated or interleaved on the shared stream (step retry/redelivery, reconnect/replay overlap, concurrent-worker duplication). ## Fix `WorkflowChatTransport` now passes the stream it hands to the AI SDK through `normalizeUIMessageStreamParts`, which mirrors the consumer's per-step part-lifetime state machine: - resets tracking on `finish-step` (exactly where the consumer resets — verified against `processUIMessageStream`); - synthesizes a missing `*-start` when an orphaned `*-delta`/`*-end` arrives; - drops a re-delivered `*-start`/`*-delta`/`*-end` for a part already open/ended in the current step. It wraps the *output* of the send/reconnect iterators, so the reconnect `chunkIndex`/`gotFinish` accounting (which counts raw server chunks) is untouched. A well-formed stream passes through unchanged. Applies to both text and reasoning parts. ## Tests `workflow-chat-transport.stream-repair.test.ts` drives the **real** transport (mock `fetch` returning chunks via the AI SDK's own `JsonToSseTransformStream`) into the **real** `readUIMessageStream` consumer: - proves the raw interleaved stream reproduces the exact `missing text part` error; - proves the transport repairs it with no content lost (`"Hello world"`); - proves a reconnect/replay duplicate tail is dropped without erroring; - proves a well-formed multi-step stream (id `"0"` reused across steps) is unchanged; - same for reasoning parts (raw interleaved reasoning is fatal; transport repairs to `"Thinking..."`). `pnpm --filter @ai-sdk/workflow build && test` pass (node + edge). ## Related - Sibling PR: vercel/workflow#2537 (the `@workflow/ai` copy) - Original issue: vercel/workflow#2422 Opened as a draft — this is an AI-assisted port across diverged copies of the same package; please review the translation before merge. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes#2422
Problem
A workflow run owns a single shared UI message stream, and the AI SDK's stream consumer (
processUIMessageStream, backinguseChat/readUIMessageStream) resets its active text/reasoning part maps on everyfinish-step. Multi-step turns reuse the same part id (commonly"0") in each step. So if atext-startis dropped or afinish-steplands in the middle of a text part, the consumer hits atext-delta/text-endfor an id it has no open part for and throws:…which kills the whole turn.
That malformed framing is reachable whenever a stream-producing step's output is duplicated or interleaved on the shared stream — e.g. step retry/redelivery, reconnect/replay overlap, or the concurrent-worker duplication tracked in #2331 / #2039 (a
finish-stepfrom one execution landing inside another's text part).Fix
WorkflowChatTransportnow passes the stream it hands to the AI SDK throughnormalizeUIMessageStreamParts, which mirrors the consumer's per-step part-lifetime state machine:finish-step(exactly where the consumer resets);*-startwhen an orphaned*-delta/*-endarrives;*-start/*-delta/*-endfor a part already open/ended in the current step (reconnect/replay overlap).It wraps the output of the send/reconnect iterators, so the reconnect
chunkIndex/gotFinishaccounting is untouched. A well-formed stream passes through unchanged; the worst case degrades to "text begins slightly into the step" or "a duplicated tail is dropped" instead of a dead turn. Applies to both text and reasoning parts.This addresses the client-visible symptom for all
WorkflowChatTransportconsumers regardless of the upstream duplication cause. The underlying server-side duplicate-execution races (#2331, #2039) are separate and remain tracked there.Tests
packages/ai/src/workflow-chat-transport.stream-repair.test.tsdrives the real transport (mockfetchreturning chunks via the AI SDK's ownJsonToSseTransformStream) into the realreadUIMessageStreamconsumer:missing text parterror;"Hello world");"0"reused across steps) is unchanged.🤖 Generated with Claude Code
Ported to
@ai-sdk/workflow:vercel/ai#16433