Streaming Output Shows Repeated Text Due to Message Merge Issue

[kfiroo]

I am experiencing issues with streaming - I believe it has to do with how we merge the messages.

Printing the streamed message content I see this:

1. Great!
2. Great! I'll find some beginner-friendly snowboards for I'll find some beginner-friendly snowboards for
3. Great! I'll find some beginner-friendly snowboards for I'll find some beginner-friendly snowboards for you.you.
4. Great! I'll find some beginner-friendly snowboards for you.

This is consistent and and I can see the issue with an without toUIMessages so I'm guessing it happens earlier when we merge the stream maybe..

---

@ianmacartney side note - I haven't been able to release a single steady version of my app with working streaming 😢

[ianmacartney]

What version of the app are you on? Have you tried the alpha with the streaming overhaul? I saw this repeating in the past due to the onChunk callback having duplicated messages when awaiting promises. So the new approach should fix this in the alpha - can you confirm it does?

[kfiroo]

with (v0.2.8-alpha.2) I am getting client side errors:

useStreamingUIMessages.ts:183 Error in stream m176z05y8p20t0chss246a3kqn7q4way: TypeError: Cannot set properties of undefined (setting 'state')
    at eval (index.mjs:3502:1)
    at runUpdateMessageJob (index.mjs:10186:1)
    at Object.transform (index.mjs:3375:1)

and

useStreamingUIMessages.ts:151 Uncaught TypeError: Failed to execute 'enqueue' on 'ReadableStreamDefaultController': Cannot enqueue a chunk into a closed readable stream
    at useStreamingUIMessages.useEffect (useStreamingUIMessages.ts:151:30)
    at basicStateReducer (react-dom-client.development.js:7065:1)
    at updateReducerImpl (react-dom-client.development.js:7175:1)
    at updateReducer (react-dom-client.development.js:7098:1)
    at Object.useState (react-dom-client.development.js:24179:1)
    at exports.useState (react.development.js:1250:1)
    at useStreamingUIMessages (useStreamingUIMessages.ts:57:53)
    at useStreamingThreadMessages (useThreadMessages.ts:243:19)
    at useThreadMessages (useThreadMessages.ts:151:23)
    at DebugPage (page.tsx:49:37)

[kfiroo]

With v0.2.8-alpha.2 there was another issue - before things crushed I saw some duplicated messages or message.parts rather

[SMBurrows]

I have the same issue with duplicated content with v0.2.8-alpha.2

[ethan-huo]

This is the same issue I encountered in version 0.2.8 a1, the Repeated Text problem, which also occurs in 0.2.7. After the streaming output completes, I have to refresh the page for the messages to return to normal.
#149

[ianmacartney]

Ok I think there are a few things happening here:

1. For some reason the stream has streaming parts coming down like "reasoning-end" or "text-end" with an id field not corresponding to an existing reasoning-start / text-start part. I can't reproduce this without intentionally corrupting mock results - so I wonder if it's coming from a specific model somehow - here it'd be really valuable to know what the stream deltas look like - e.g. what they are for stream ID m176z05y8p20t0chss246a3kqn7q4way in the original post.
2. The ReadableStream is being updated when the UIMessage is no longer active somehow. I'm going to move those to the same useEffect in case that is the issue - otherwise I'd love to know if folks are seeing this during error-related behavior (e.g. the stream aborting).
3. The text deleting issue may be related to having the UIMessage being created across message page boundaries - e.g. there's a tool call message on the end of one page that becomes one UIMessage, then a tool response on the next page that becomes a separate UIMessage - I can work on this, this is the clearest reason for some of the behavior. If this is happening with tool calls, you should see Tool result without preceding tool call.. adding anyways in your logs.

For the duplication issue - between 2.7 and 2.8 the streaming logic changed dramatically so if folks are seeing duplicate content I suspect it's from a different source than before.

@SMBurrows @ethan-huo @kfiroo I'd love to know:

1. Are you using useUIMessages, useThreadMessages, or something else?
2. Are you seeing this reliably on every message, or only occasionally (e.g. could be on a page boundary)? Is it related to message failures at all - are there multiple assistant responses w/o tool calls or retries happening e.g.?
3. Is the duplicate content "text" content, "reasoning", or part of tool input / output? If it's only related to tools that could be due to the page boundary. If it's only "text", then is it duplicated within one message, duplicate "text" parts, or something else?
4. Does the duplication resolve after streaming is finished? After a page refresh?

Update: The latest alpha has that change for (2)

[kfiroo]

@ianmacartney Thanks for shading light on this 🙏🏼

Regarding your initial thoughts:

1. What is the best way to get the stream deltas? I can paste it here and we can investigate.
   • Breaking on error I see the part that failed to enqueue is part: {type: 'finish-step'}
2. No error/abort in my case. I have a fresh empty thread and I send a message that calls a single tool and streams a result.
3. I did see Tool result without tool call.. errors before and that actually can explain it in cases where threads start to grow but this is not the case here as in my current test setup I have a max of 4 messages in a thread.

As for the information you need:

1. I am using useThreadMessages - I can create a reproduction repo if you think its useful.
2. Simple setup - I click a button which creates a new thread and sends a message that is handled by a single agent with a single RAG tool. The UI is waiting for messages to stream via useThreadMessages
3. My agent responds with text part - tool call - text part and I see the text parts duplicated. My setup makes me think its not page boundary related.
4. I'm using next and currently my page just blows up when the errors are thrown so not sure about the streaming end but after refresh it looks fine

[vtsmburrows]

Answering your questions:

1. I am using useUIMessages - I took the implementation from the the examples folder here. The only differences are that I'm using NextJS, and I am using Vercel AI Elements for the rendering. I don't believe the component rendering is part of the issue as I see duplicated text in the console before rendering the messages array

2. I was seeing it on a fairly complex setup (MCP Servers, RAG) - so to eliminate that I created a simple implementation which was just a basic agent (instructions and model). Have the same issue with both setups. I did also try different models (GPT-5, GPT-5 Mini, GPT-4.1, GPT-4.1 Mini, Llama 4 Scout, Gemini 2.5 Flash, and a few more) they all share the same issue so don't believe that it's the model

3. I see duplication in the text parts, the reasoning parts do have a different bug though, I'll get an empty reasoning part, followed by one that has data for every part.

4. I've had a mix. If I use a non-reasoning model I don't need to refresh. On reasoning models I see Failed to execute 'enqueue' on 'ReadableStreamDefaultController' error which kinda forces me to refresh

• I posted on my work account answering for SMBurrows

[ianmacartney]

@kfiroo A reproduction would be very helpful!

For the deltas, you can to dashboard.convex.dev/deployment/data and go to the agent component tables, then copy out of streamingDeltas after selecting them: dashboard UI.

1. What model are you using, and any special call settings / provider options? I can't repro with openai & basic tool calling unfortunately.
2. And just to confirm, there's an empty thread, a user prompt, and then a series of 3 messages, a tool call, tool result, then assistant response, and you see disappearing text.
3. Is the text from the same assistant response that did the tool calls? Or saved as a separate message from the agent somehow.
4. The errors are thrown client-side, right? Or while server rendering somehow?

FYI: you can pass options to listMessages and syncStreams to return different message statuses - by default the streaming messages only include streaming messages, but the listMessages I think includes everything by default.

[ianmacartney]

And using the latest alpha would be a good sanity check - the 2 & 3 issues might be remedied through some improvements there. I'll try harder to repro the issues.

Also - npm ls ai @ai-sdk/provider-utils @ai-sdk/* would be useful to know - maybe the step ordering or readable stream parsing has changed - I know they had a bug in 5.0.7 that seems to have been fixed by 5.0.29

[SMBurrows]

For the deltas, you can to dashboard.convex.dev/deployment/data and go to the agent component tables, then copy out of streamingDeltas after selecting them: dashboard UI.

I've attached a delta from my environment and a screenshot

Interestingly I do not see the duplicate content in the delta (I did 3-4 tests where it showed on the front end but not in the DB)

delta.js

In the client logging messages (which is directly from useUIMessages:

dependencies the only ones I have that are relevant to this are:

@ai-sdk/gateway 1.0.19
@convex-dev/agent 0.2.8-alpha.2
ai 5.0.34
convex 1.26.2```

[kfiroo]

@ianmacartney I have this simple repro app https://convex-streaming-test.vercel.app (repo)

One thing I noticed is that I don't have any issues in production build!
That makes me think that we might have an issue due to React StrictMode in dev.. not sure how or why, just throwing my gut feeling out here..

In dev mode I consistently see duplicated text and then the 2 errors:

Versions:

@ai-sdk/openai 2.0.27
@convex-dev/agent 0.2.8-alpha.2
ai 5.0.37
convex 1.26.2
next 15.5.2
react 19.1.1
react-dom 19.1.1
zod 4.1.5

[ianmacartney]

Wow, nice catch @kfiroo. Indeed I haven't had strict mode on (possibly back when I was first messing with stateful client stuff). Strict mode indeed breaks it immediately.

And that makes a lot of sense - dual-execution of applying deltas would duplicate applying text, dual-applying "text-end" parts throws b/c there wouldn't be a text part to end anymore, and trying to close a stream twice fails.

So the users have been fine all along. Ok I'm going to look into ways of making this work with strict mode, but if folks can go without strict mode for now, that should unblock your development. Sorry it took this long to diagnose!

[SMBurrows]

Confirmed my production build doesn't have the issue too!