reconnectToStream sends RESUME_REQUEST before WebSocket is open

Problem

WebSocketChatTransport.reconnectToStream() sends CF_AGENT_STREAM_RESUME_REQUEST after a fixed 100ms setTimeout, but after a page refresh the WebSocket hasn't opened yet at that point. The agent.send() throws, the try/catch swallows it, and after the 3s timeout the method returns null → status stays "ready".

Result: After refreshing during an active stream, the text eventually appears (via onAgentMessage), but useChat status never transitions to "streaming" — no abort button, no loading indicator.

Where

WebSocketChatTransport.reconnectToStream() in packages/ai-chat/src/react.ts:

const requestDelay = setTimeout(() => {
  if (!resolved) try {
    agent.send(JSON.stringify({ type: MessageType.CF_AGENT_STREAM_RESUME_REQUEST }));
  } catch {}
}, 100);

The 100ms delay was added to avoid a race with the server's automatic CF_AGENT_STREAM_RESUMING in onConnect, but it doesn't account for WebSocket connection time — which is almost always longer than 100ms on a fresh page load.

Suggested fix

Wait for the WebSocket to be open before sending:

function sendWhenOpen(agent, message) {
  if (agent.readyState === WebSocket.OPEN) {
    agent.send(message);
  } else {
    agent.addEventListener("open", () => agent.send(message), { once: true });
  }
}

On page refresh, reconnectToStream is called while the WebSocket readyState is 3 (CLOSED). PartySocket queues the outgoing RESUME_REQUEST, but the onDetect event listener is registered on a not-yet-connected socket. By the time PartySocket reconnects and the server responds with STREAM_RESUMING, the 3s timeout has already fired and removed the onDetect listener. Nobody receives the response.

Console output:

[RESUME] reconnectToStream called, agent readyState: 3
[RESUME] sending RESUME_REQUEST (100ms backup)
[RESUME] 3s timeout — no STREAM_RESUMING received, resolving null

PartySocket queues outgoing send() calls, but incoming addEventListener("message", ...) listeners registered before the socket opens do NOT receive messages that arrive after reconnection — the listener is on the old internal WebSocket instance.

The fix should either wait for the WebSocket to be open before starting the detection flow, or ensure the listener survives reconnection.

good catch. Ill update the PR

btw thanks so much for the detailed reports and your patience. it's a tricky thing to solve, and it's great having info like this to work on.

ok try this one again npm i https://pkg.pr.new/cloudflare/agents/@cloudflare/ai-chat@999

The fix looks good in the source but the pkg.pr.new tarball still has the old built output. Did the preview build not re-trigger on the force push?

hmm probably not, they've been having issues

I'll generate a fresh build in a bit, afk

this build should point at the latest hash npm i https://pkg.pr.new/cloudflare/agents/@cloudflare/ai-chat@81acb00

@threepointone

@threepointone Tested the new build (@81acb00). The transport listener never receives STREAM_RESUMING — onAgentMessage handles it first via the fallback path, which doesn't set status to streaming.

Debug logs after refreshing while the model is thinking:

[RESUME] reconnectToStream called, readyState: 3
[RESUME] sent RESUME_REQUEST
[RESUME] reconnectToStream called, readyState: 3
[RESUME] sent RESUME_REQUEST
[RESUME] onAgentMessage got STREAM_RESUMING, id: p12iwdDZ localIds: Array(0)
[RESUME] onAgentMessage handling STREAM_RESUMING via fallback path

Two issues:

reconnectToStream is called twice (React strict mode double-effect), both with readyState 3
localRequestIdsRef is empty when STREAM_RESUMING arrives, so onAgentMessage doesn't skip it. The transport's addEventListener("message", onMessage) never fires.

~~Thanks for reporting again. Could you try npm i https://pkg.pr.new/@cloudflare/ai-chat@5ad1325?~~

Actually, try this one npm i https://pkg.pr.new/@cloudflare/ai-chat@b466803

@threepointone

@threepointone Tested @b466803. The handleStreamResuming / _resumeResolver approach is correct, but there's a transport instance mismatch that prevents it from working.

The problem: useAgentChat creates customTransport via useMemo, but the useChat ChatStore (backed by useRef) captures the transport at construction time. In React Strict Mode (dev), useMemo produces new instances across re-renders, so the ChatStore holds transport #1 while the onAgentMessage effect closure captures transport #3. reconnectToStream sets _resumeResolver on #1, but handleStreamResuming checks #3 — which never had a resolver.

Debug logs after refresh-during-stream:

WebSocketChatTransport created, id: 1
WebSocketChatTransport created, id: 2
reconnectToStream called on transport: 1    ← ChatStore uses this one
sent STREAM_RESUME_REQUEST
reconnectToStream called on transport: 1
sent STREAM_RESUME_REQUEST
WebSocketChatTransport created, id: 3
WebSocketChatTransport created, id: 4
onAgentMessage got STREAM_RESUMING, id: omZXz_PZ
handleStreamResuming called on transport: 3 has resolver: false    ← but onAgentMessage checks this one
transport did NOT handle, using fallback path
reconnectToStream 5s timeout fired
reconnectToStream done(), value: null

The fallback path in onAgentMessage does resume the stream (messages come through), but it bypasses useChat's makeRequest flow entirely, so status stays "ready" instead of "streaming".

Fix: The transport needs to be a stable reference. Either:

Use useRef instead of useMemo for customTransport so the same instance is shared
Or have onAgentMessage access the transport through the ChatStore ref instead of closing over it

// Option 1: stable ref
const customTransportRef = useRef<WebSocketChatTransport>(null);
if (!customTransportRef.current) {
  customTransportRef.current = new WebSocketChatTransport({ ... });
}
const customTransport = customTransportRef.current;

Here's another try npm i https://pkg.pr.new/@cloudflare/ai-chat@60c58bf

Ignore my Strict Mode comments — that wasn't it. Tested in production mode with logging. After refreshing during streaming:

Transport created, tid: 1
reconnectToStream on tid: 1 readyState: 3    ← WS closed, resume request silently fails
Transport created, tid: 2                     ← _pk changed, new transport
STREAM_RESUMING received, tid: 2 resolver: false  ← resolver stranded on tid:1
fallback path used
done() on tid: 1 value: null                  ← 5s timeout, status → "ready"
Transport created, tid: 3                     ← _pk changed again

_pk changes 3 times during reconnection, recreating the transport each time. The resolver is always on a previous transport that onAgentMessage no longer references. Is this expected for _pk?

I think the fix is:

Don't recreate the transport on _pk changes — create once with useRef, update this.agent in-place each render
Use customTransportRef.current in onAgentMessage instead of the closure-captured customTransport (and remove it from the effect deps)
Wait for the WebSocket to be open before sending STREAM_RESUME_REQUEST (readyState was 3 when reconnectToStream fired)

With (1) and (2) applied locally, the resolver is found and the stream handshake completes.

what user facing bug are you seeing?

When refreshing the page while the model is thinking/streaming, the "Thinking..." status doesn't persist. The status goes back to "ready" so the user can send a new message even though the model is still working. The response does eventually come through via the fallback path, but useChat's status is wrong.

I believe our PR fixes that exact scenario, does it not for you?

Like, it's fine if it shows ready while it connects, there's no real way to solve that until the websocket connects (unless you're storing some client side state)

The issue is that it stays "ready" permanently, even after the WebSocket reconnects and the server sends STREAM_RESUMING. The transport that receives the STREAM_RESUMING message is a different instance than the one holding the resolver (because _pk changed and a new transport was created), so the resolver is never called and the status never transitions to "streaming".

can you make a repro? I need to see if you're using an async query or something. you can use the agent starter if that helps https://github.com/cloudflare/agents-starter

I'm putting up a fix for async queries, but I'd still love a repro if possible

try npm i https://pkg.pr.new/@cloudflare/ai-chat@807365f I bet it's all solved now

@807365f didn't fix it — chat history disappears after refresh now (initialMessages comes back empty). Will put together a minimal repro when I have time.

Minimal repro for cloudflare/agents#1000

@threepointone

Hey @threepointone — turns out this was on my end. I had set getInitialMessages: null in my useAgentChat call and was fetching messages manually as a workaround a while back, and forgot about it. That bypassed the SDK's Suspense-based message loading, which is what enables stream resumption.

Once I removed that and let the SDK use its default getInitialMessages, resume works as expected. Thanks for looking into it and for the singleton transport fix!

Fantastic glad we got here! I'll merge the pr now. Thanks for digging deep with me!

Navigation Menu

reconnectToStream sends RESUME_REQUEST before WebSocket is open #1000

Problem

Where

Suggested fix

Related

2 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

reconnectToStream sends RESUME_REQUEST before WebSocket is open #1000

Description

Problem

Where

Suggested fix

Related

Activity

alexanderjacobsen commented on Feb 26, 2026

alexanderjacobsen commented on Feb 26, 2026

threepointone commented on Feb 26, 2026

threepointone commented on Feb 26, 2026

threepointone commented on Feb 26, 2026

alexanderjacobsen commented on Feb 27, 2026

threepointone commented on Feb 27, 2026

threepointone commented on Feb 27, 2026

alexanderjacobsen commented on Feb 28, 2026

threepointone commented on Feb 28, 2026

threepointone commented on Feb 28, 2026

alexanderjacobsen commented on Feb 28, 2026

threepointone commented on Feb 28, 2026

2 remaining items

alexanderjacobsen commented on Feb 28, 2026

alexanderjacobsen commented on Feb 28, 2026

threepointone commented on Feb 28, 2026

alexanderjacobsen commented on Feb 28, 2026

threepointone commented on Feb 28, 2026

threepointone commented on Feb 28, 2026

alexanderjacobsen commented on Feb 28, 2026

threepointone commented on Feb 28, 2026

threepointone commented on Feb 28, 2026

threepointone commented on Feb 28, 2026

alexanderjacobsen commented on Feb 28, 2026

alexanderjacobsen commented on Feb 28, 2026

threepointone commented on Feb 28, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions