fix(think): preserve regeneration branches after restart

[ben-reitz]

Stacked on #2038.

What users see

The parent PR fixes regenerated answers using the wrong conversation branch. One restart case remained: if the server's Durable Object restarted while a regenerated answer was streaming, the recovered text could be saved beneath the original answer instead of beside it.

flowchart TB
  subgraph after["After"]
    AU["User message"] --> AO["Original answer"]
    AU --> AR["Recovered regeneration"]
  end

  subgraph before["Before"]
    BU["User message"] --> BO["Original answer"]
    BO --> BR["Recovered regeneration"]
  end

Loading

Why it happens

The streamed text survives a restart because it is stored in SQLite. The message it belongs beside did not: that link only lived in memory. After a restart, Think still had the words, but had forgotten where to put them.

The fix

Resumable streams now save that optional parent link with their existing metadata. When Think rebuilds an interrupted answer, it reads the link back and restores the answer to the right branch.

Existing rows keep the old fallback behavior. Conversations that do not branch also keep using the existing schema until they actually need this field.

Tests

A new WebSocket test disables automatic chat recovery, forces a Durable Object restart, acknowledges the resumed stream, and checks that the recovered answer is a sibling of the original. Migration tests cover both old databases and ordinary linear streams.

Suites: think 925 · agents workers 1746 · agents chat 514 · ai-chat workers 655 · pnpm run check.

---

[changeset-bot]

⚠️ No Changeset found

Latest commit: 5a43800

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[devin-ai-integration]

✅ Devin Review: No Issues Found

Devin Review analyzed this PR and found no potential bugs to report.

View in Devin Review to see 1 additional finding.

[pkg-pr-new]

Open in StackBlitz

agents

npm i https://pkg.pr.new/agents@2057

@cloudflare/ai-chat

npm i https://pkg.pr.new/@cloudflare/ai-chat@2057

@cloudflare/codemode

npm i https://pkg.pr.new/@cloudflare/codemode@2057

hono-agents

npm i https://pkg.pr.new/hono-agents@2057

@cloudflare/shell

npm i https://pkg.pr.new/@cloudflare/shell@2057

@cloudflare/think

npm i https://pkg.pr.new/@cloudflare/think@2057

@cloudflare/voice

npm i https://pkg.pr.new/@cloudflare/voice@2057

@cloudflare/worker-bundler

npm i https://pkg.pr.new/@cloudflare/worker-bundler@2057

commit: 5a43800

[devin-ai-integration]

Devin Review found 1 new potential issue.

View 2 additional findings in Devin Review.

[devin-ai-integration]

🟡 Reconnecting users can see a follow-up answer duplicated as a new message instead of continuing the previous one

The follow-up-answer marker is left off when the resumable stream is opened (_startResumableStream(requestId, { parentMessageId: parentId }) at packages/think/src/think.ts:12607-12609) even though live frames carry it, so a user who reconnects mid-answer sees the replayed text split into a separate duplicate message.
Impact: After a brief disconnect during a tool-driven follow-up answer, the chat shows a second, partial copy of the answer instead of the continued one.

Replay frames lose the `continuation` flag because `ResumableStream._activeIsContinuation` is never set for Think

ResumableStream.start derives _activeIsContinuation and the durable is_continuation column solely from options.continuation (packages/agents/src/chat/resumable-stream.ts:290). Think's _streamResult computes const continuation = options?.continuation ?? false and adds continuation: true to every live broadcast frame (packages/think/src/think.ts:12757-12762), but never passes it to start, so the row is written with is_continuation = 0 and _activeIsContinuation stays false.

Replay is the only other producer of those frames: replayChunks (packages/agents/src/chat/resumable-stream.ts:525) and replayCompletedChunksByRequestId/replayErroredChunksByRequestId (:621, :668) gate continuation: true on that state. The client branches on the flag when applying frames (packages/agents/src/chat/react.tsx:2101, :2127, :2210, :2267-2268): without it a replayed continuation start (whose messageId is deliberately omitted for continuations, packages/think/src/think.ts:11933) is treated as a fresh message and the pre-continuation parts are dropped — the same failure #1733 fixed for AIChatAgent. This PR rewrites exactly this start option object, so the omission is easy to fix here.

Suggested change

	const streamId = this._startResumableStream(requestId, {
	parentMessageId: parentId
	});
	const continuation = options?.continuation ?? false;
	const streamId = this._startResumableStream(requestId, {
	parentMessageId: parentId,
	continuation: options?.continuation ?? false
	});

---

Was this helpful? React with 👍 or 👎 to provide feedback.