Repository navigation
fix: report continuation turns that fail before streaming (#2381) - #2393
Merged
threepointone merged 3 commits intoSep 28, 2026
Merged
threepointone merged 3 commits into
threepointone merged 3 commits into
Conversation
threepointone
added this pull request to stack #2395
September 28, 2026 10:50
🦋 Changeset detectedLatest commit: 11f484c The changes in this PR will be included in the next version bump. This PR includes changesets to release 3 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
Contributor
|
✅ agents import sizes: no significant changes ( |
threepointone
force-pushed
the
fix/2381-continuation-prestream-errors
branch
from
September 28, 2026 10:57
9747261 to
c1da263
Compare
threepointone
marked this pull request as ready for review
September 28, 2026 10:57
agents
@cloudflare/ai-chat
@cloudflare/codemode
hono-agents
@cloudflare/shell
@cloudflare/think
@cloudflare/voice
@cloudflare/worker-bundler
commit: |
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
Comment on lines
+18705
to
+18712
| this._broadcastChat({ | ||
| type: MSG_CHAT_RESPONSE, | ||
| id: requestId, | ||
| body: errorMessage, | ||
| done: true, | ||
| error: true, | ||
| continuation: true | ||
| }); |
Contributor
There was a problem hiding this comment.
🔍 Replayed continuation errors lack the continuation flag
Live continuation failures carry continuation: true, but terminal replay reconstructs error frames without it. Check whether reconnecting chat clients need that flag to associate the error with the pending continuation.
Was this helpful? React with 👍 or 👎 to provide feedback.
threepointone
force-pushed
the
fix/2381-continuation-prestream-errors
branch
from
September 28, 2026 11:36
c1da263 to
452db97
Compare
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
When an auto-continuation or a connection-less continuation throws before it streams (for example from beforeTurn or onChatMessage), report it like a failed turn: an error frame for the continuation, onChatResponse with status "error", and a recorded terminal status. Think also calls onChatError with stage "turn" and continuation: true, and emits chat:request:failed. Co-authored-by: Cursor <cursoragent@cursor.com>
Addresses review on #2393: _reply now signals when it takes over reporting (onStreamStart), and takes the body reader before starting the resumable stream, so an unreadable body fails before anything was sent and is reported by the continuation. Co-authored-by: Cursor <cursoragent@cursor.com>
…ok; release the reader on stream setup failure Co-authored-by: Cursor <cursoragent@cursor.com>
threepointone
force-pushed
the
fix/2381-continuation-prestream-errors
branch
from
September 28, 2026 11:58
452db97 to
11f484c
Compare
Merged
tombeckenham
added a commit
to tombeckenham/agents-tom
that referenced
this pull request
Oct 7, 2026
…ry for transient reader errors Ports upstream cloudflare#2194, cloudflare#2190, cloudflare#2223, cloudflare#2360, cloudflare#2385 and cloudflare#2393 to AGUIChatAgent. - Recovery attempts are __cf_internal_chat_recovery Task runs dispatched to the model handoff; a root agent's chat turn is a Task run (facets stay on fibers). The origin-ids scope moves into the dispatch wrapper. - The progress marker is derived from the stream log; a settled TOOL_CALL_RESULT is flushed as it lands. - A platform-transient reader error routes into bounded recovery like a stall: onChatRecovery is consulted with the live turn's stash data, persist:false drops the partial, a blank new turn is retried, and a running attempt that reschedules leaves the incident to its successor. - A cancel during backoff cancels the queued recovery. - An auto-continuation that fails before streaming sends an error frame and reaches onChatResponse. The agui test worker follows the Tasks transport and the derived marker.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #2381. Stacked on #2392.
Problem
When an auto-continuation (after a tool approval or a client tool result) or a connection-less continuation threw before streaming, for example from
beforeTurnoronChatMessage, the failure was only logged. Clients got no error frame,onChatResponsenever fired, and no terminal status was recorded. The conversation looked like it was still waiting.Change
A continuation that fails before streaming is now reported like any other failed turn:
cf_agent_use_chat_responseframe withcontinuation: trueonChatResponsewithstatus: "error"andcontinuation: true, for the assistant message the continuation would have extendedThink also calls
onChatError(error, { stage: "turn", continuation: true })and emitschat:request:failed.continuationis a new optional field onChatErrorContext.Aborts and Durable Object resets are not reported, since their own paths handle them. Failures after streaming starts are unchanged:
_streamResultand_replyalready report those. Per the decision on the issue, this only reports the failure. The approval part itself is settled by #2392 on the next new turn.Tests
beforeTurn(WebSocket), and a connection-less continuation afterapproveExecution(no socket). Both check that the failure is reported exactly once.onChatMessage.