v5 mutates message parts which causes problems with the React Compiler

[zhm]

Description

When processing the stream inside processUIMessageStream, it mutates the message part, which doesn't update the message object reference itself in the messages array. This ends up causing the messages to never re-render if this is the only change that happens in the stream. Example: a tool call continuation. When I disable the react compiler it re-renders fine. The fix is to copy the messages array in my message list component, but that is obviously a workaround.

ai/packages/ai/src/ui/process-ui-message-stream.ts

Line 120 in 0463011

part.toolInvocation = invocation;

AI SDK Version

5.0.0-alpha.4

[iteratetograceness]

@zhm could you share a small reproduction? Would love to better understand what you're seeing and what you mean by tool call continuation (e.g. client-side tool call?)

[zhm]

@iteratetograceness sure! When I say tool call continuation, I mean emitting a human in the loop result and then "continuing" it from the client using a button.

Here is a repo with the bug reproducible. The caveat is that this reproduction depends on also patching #6435

To reproduce this issue you will have to remove the await here to get past #6435

ai/packages/ai/src/ui/chat-store.ts

Line 392 in b346545

await this.triggerRequest({

This example repo is also a reproduction case for that issue.

1. Run the app pnpm dev
2. Go to /confirm
3. Click the Confirm button and it will simulate making a human in the loop tool call continuation
4. It show the actual messages at the bottom, and the messages in the chat are out of sync
5. If you comment out reactCompiler: true in next.config.js and refresh, it will work correctly

[ItsWendell]

I've been having a lot of issues with rendering in general with v5 experiments too, where the messages returned from the useChat hook (coming from the chat store) are not reactive at all to what I'm doing. I'm seeing the same issues in https://github.com/vercel/ai-chatbot/tree/jrmy/v5 where they now just forcefully always re-render the components instead of memoizing, and that's in next.js dev mode, not even with react compiler on.

[zhm]

My reproduction case above is actually a more complex case because it's also testing another bug with addToolResult. I added a newer test case that's much simpler to reproduce and easier to understand since addToolResult adds unneeded complexity to reproduce this bug.

Simpler reproduction case:

• https://github.com/zhm/ai-sdk-test
• pnpm dev
• http://localhost:3000/react-compiler
• Enter any message and click submit
• It only renders the step-start message
• Disable reactCompiler in next.config.js
• It now works

[iteratetograceness]

@zhm to address your main concern around incompatibility with the experimental React Compiler: this is caused by the compiler pre-optimizing the Message component with memo (you can opt out with 'use no memo' if you'd like to continue using the experimental feature)!

[iteratetograceness]

Hi @ItsWendell! Could you help share some concrete examples to better illustrate your issues?

[ItsWendell]

@iteratetograceness I think the best example is in the ui-chatbot package on the v5 branch right here:

https://github.com/vercel/ai-chatbot/blob/00f3553e18677ad9d7962a77f450548d43668844/components/message.tsx#L244

The memo arePropsEqual function is currently set to false, which forces re-renders. When experimenting by uncommenting some of these conditions with what you'd expect to work in React, it doesn't rerender when you expect it to rerender properly. I believe this is because the object references are staying the same for messages and parts, which causes the same issues as @zhm is experiencing.

The issue stems from the fact that processUIMessageStream mutates message parts in-place:

part.toolInvocation = invocation; // This mutates the existing object

This means:

1. The message object reference stays the same
2. The parts array reference stays the same
3. Only the content within a part changes
4. React's reconciliation (especially with React Compiler) doesn't detect these deep mutations
5. Components don't re-render even though the data has changed

My hacky workaround

I've implemented a custom MessageProvider that works around this by:

1. Deep cloning messages when changes are detected
2. Tracking previous state with refs to avoid unnecessary re-renders
3. Optimized change detection that compares the actual content, not just references

Here's the key part of my implementation:

const updateMessages = useCallback(() => {
  setMessages((prev) => {
    const currentMessages = store.getMessages(chatId);
    const lastMessage = store.getLastMessage(chatId);

    // Fast path: no messages
    if (!lastMessage || !prevLastMessage.current) {
      prevLastMessage.current = lastMessage ? cloneDeep(lastMessage) : null;
      prevMessagesLength.current = currentMessages.length;
      return [...currentMessages];
    }

    // Check if the last message has changed (streaming scenario)
    if (hasMessageChanged(prevLastMessage.current, lastMessage)) {
      const clonedLastMessage = cloneDeep(lastMessage);
      prevLastMessage.current = clonedLastMessage;

      if (prev.at(-1)?.id === clonedLastMessage.id) {
        // Only clone and update the last message for performance
        return [...prev.slice(0, -1), clonedLastMessage];
      }
      return [...prev, clonedLastMessage];
    }
    return prev;
  });
}, [chatId, store, setMessages]);

And the change detection logic:

export const hasMessageChanged = (prev: UIMessage, next: UIMessage): boolean => {
  // Fast path: same reference
  if (prev === next) return false;

  // For streaming scenarios, compare the last part content
  const lastPrevPart = prev.parts.at(-1);
  const lastNextPart = next.parts.at(-1);

  if (!lastPrevPart || !lastNextPart) {
    return true;
  }

  // For text parts, compare text directly (most common case)
  if ("text" in lastPrevPart && "text" in lastNextPart) {
    return lastPrevPart.text !== lastNextPart.text;
  }

  // For other parts (like tool calls), use deep comparison
  return !fastDeepEqual(lastPrevPart, lastNextPart);
};

Why This Works

1. New object references: By using cloneDeep, we create new object references that React can detect
2. Optimized updates: We only clone and update when actual content changes
3. Performance: We avoid unnecessary deep clones by comparing content first
4. React Compiler compatible: Since we're creating new references, React Compiler's optimizations work correctly

The proper solution would be for the AI SDK to do something similar in useChat for example for React. This would make the SDK naturally compatible with React's reconciliation and optimization tools like React Compiler. An alternative is to provide utilities and documentation for developers to understand how reactivity works and help around these issues.

The current workaround works, but it adds complexity and performance overhead that shouldn't be necessary if the SDK handled it properly.

[remorses]

This is also a problem if you use React.memo on the components that render the messages. The message objects and message.parts arrays are mutated, which means that the components props keep the same identity between renders and never render on new text.

[lgrammel]

@iteratetograceness is this still an issue after your fix or can we close this ticket?