useAgentChat: "Maximum update depth exceeded" thrown during stream resume after a reconnect — surfaces as a terminal error mid-turn (not fixed by #1838)

[mrgarcia1998]

Describe the bug

When a chat client's WebSocket closes mid-turn and PartySocket auto-reconnects, the resumed stream's replayed chunks drive a synchronous re-render cycle inside the shared chat hook (agents/chat/react, consumed via @cloudflare/think/react): onAgentMessage → ReactChatState set messages → forceStoreRerender → … repeating until React's update-depth guard throws Maximum update depth exceeded.

The exception escapes through useAgentChat's catch path, so the client lands in status: "error" with error set mid-turn — while the durable turn on the agent DO is healthy and completes normally (verified in the DO message store: stream metadata completed, full assistant reply persisted).

#1838 does not fix this: with resumes serialized, a single close + its one resumed stream is still enough to trigger the loop. Reproduced in 3 separate runs on the versions below.

To Reproduce

1. A Think-based agent with chat over useAgent + useAgentChat (defaults — resume on).
2. Start a long streaming turn (a multi-second reply is enough).
3. Close the underlying WebSocket once mid-stream (e.g. grab the raw socket and call .close(); PartySocket auto-reconnects).
4. On reconnect the stream resumes and replays; the browser console shows the Maximum update depth exceeded React error, and useAgentChat reports status: "error" + a set error while the server-side turn keeps running.

Expected behavior

A resumed stream replays without tripping React's update-depth guard — and in general, a client-side rendering failure should not mark a turn as terminally errored while it is still running (and later completes) server-side. The false terminal error also cascades into a second bug (filed separately, linked below): once the client sits in "error", stream resume never re-arms, so isServerStreaming can stick true forever.

Version:

agents@0.17.3, @cloudflare/think@0.12.1, ai@6.0.205, @ai-sdk/react@3.0.207, react@19.2.7, partysocket@1.3.0. Observed both under local wrangler dev and in production.

Additional context

Found while adopting the #1799 connectionError surface. Downstream we mitigate with an error-triggered debounce + a bounded getMessages reconciliation loop, but the root loop lives in the shared hook's message-replay path. Happy to provide the full captured stack / more repro detail if useful.

[mrgarcia1998]

The companion issue is #1914 — the resume-on-open re-arm gap that keeps isServerStreaming stuck true after this bug puts the client in "error". Together they wedge the client until a full reload.

[rasmaadhi]

I'm experiencing the same issue with agents@0.17.3 and @cloudflare/ai-chat@0.9.3.

My setup:

• React 19.2.7
• useAgent + useAgentChat with default options
• Chat with file attachments and tool calls

Symptoms:

• Console shows Maximum update depth exceeded error
• Stack trace points to set messages in @cloudflare/ai-chat/react.js
• Error happens intermittently during streaming
• App continues to work despite the error

Additional context:
The error occurs when the WebSocket reconnects mid-stream. The setMessages wrapper in useAgentChat sends cf_agent_chat_messages back to the server, which can trigger a feedback loop when the server responds with the same message type.

This is blocking adoption of the agents SDK for production use. Hoping for a fix soon!

[xcaptain]

Same error here, please fix it soon

[magicismight]

We hit this in production as well (agents@0.17.3 via @cloudflare/ai-chat@0.9.3, React 19.2.7): a ~9-minute turn, one mid-turn reconnect, then the React #185 throw escaping useAgentChat into a false terminal status: "error" while the server-side turn completed fine — with the replayed text visibly re-typing before the crash.

One detail worth adding to the diagnosis: the broadcast-state transition() machine already batch-applies replayed chunks on the fallback (non-transport-owned) path — messagesUpdate is only emitted at replayComplete/done. The gap is the transport-owned path (same-tab reconnect, request id still in activeRequestIds): _createResumeStream / _createToolContinuationStream forward every replay: true frame into the UI-message stream individually, and the burst outpaces React's commit loop (useSyncExternalStore's store-consistency check schedules SyncLane re-renders that experimental_throttle doesn't cover).

We have a working fix on a fork branch that maintainers are welcome to pull from — we weren't able to open a PR against this repo (creation is restricted for us):

https://github.com/magicismight/agents/tree/fix-replay-burst-batching (single commit, includes a changeset)

What it does:

• Both resume streams buffer replay: true chunks in a ReplayChunkBuffer instead of enqueuing them per frame; consecutive text-delta / reasoning-delta / tool-input-delta chunks of the same part are merged (deltas carrying providerMetadata are kept whole; cross-part ordering preserved), and the compacted batch is delivered once at the replay boundary (replayComplete, done, or the first live chunk). Applying the replayed prefix becomes O(parts) instead of O(chunks), and replayed text appears at once instead of re-typing.
• The errored-turn resume path (Clarify in-band stream error replay and agent-tool terminal status #1575: partial content replayed before the terminal error frame) is preserved: with a non-empty buffer the error is delivered as a {type: "error"} UI chunk behind the flushed batch (rethrown by useChat's onError into the same terminal-error path), since controller.error() would discard the still-queued content.
• 10 new tests (ws-chat-transport-replay.test.ts); the full chat project suite passes (524).

Happy to provide more detail or adjust the approach if maintainers prefer a different shape.