-
-
Notifications
You must be signed in to change notification settings - Fork 79.2k
LLM idle timeout error silently dropped when agentRunStarted is true #84945
Copy link
Copy link
Closed
Copy link
Labels
P1High-priority user-facing bug, regression, or broken workflow.High-priority user-facing bug, regression, or broken workflow.clawsweeper:fix-shape-clearClawSweeper found a clear likely implementation shape for this issue.ClawSweeper found a clear likely implementation shape for this issue.clawsweeper:queueable-fixClawSweeper marked this issue as an existing queue_fix_pr work candidate.ClawSweeper marked this issue as an existing queue_fix_pr work candidate.clawsweeper:source-reproClawSweeper found a high-confidence source-level issue reproduction.ClawSweeper found a high-confidence source-level issue reproduction.impact:message-lossChannel message delivery can be lost, duplicated, or misrouted.Channel message delivery can be lost, duplicated, or misrouted.issue-rating: 🦞 diamond lobsterVery strong issue quality with high-confidence source-level or clear reproduction.Very strong issue quality with high-confidence source-level or clear reproduction.
Metadata
Metadata
Assignees
Labels
P1High-priority user-facing bug, regression, or broken workflow.High-priority user-facing bug, regression, or broken workflow.clawsweeper:fix-shape-clearClawSweeper found a clear likely implementation shape for this issue.ClawSweeper found a clear likely implementation shape for this issue.clawsweeper:queueable-fixClawSweeper marked this issue as an existing queue_fix_pr work candidate.ClawSweeper marked this issue as an existing queue_fix_pr work candidate.clawsweeper:source-reproClawSweeper found a high-confidence source-level issue reproduction.ClawSweeper found a high-confidence source-level issue reproduction.impact:message-lossChannel message delivery can be lost, duplicated, or misrouted.Channel message delivery can be lost, duplicated, or misrouted.issue-rating: 🦞 diamond lobsterVery strong issue quality with high-confidence source-level or clear reproduction.Very strong issue quality with high-confidence source-level or clear reproduction.
Type
Fields
Give feedbackNo fields configured for issues without a type.
Bug Description
When an LLM idle timeout occurs after the agent has started (e.g., after tool calls), the error is written to the session log but never broadcast to connected clients. Users see no error feedback — the response silently stops.
Reproduction
agentRunStarted = true)Session Log Evidence
The session ends here — no final/error event is broadcast.
Root Cause
File:
src/gateway/server-methods/chat.ts(.then()handler, ~line 2692 in main)The timeout error flows like this:
run.tshandles the timeout by returning an error payload ({ text: "...", isError: true }), not throwing an exceptiondeliveredRepliesvia thedelivercallback.then()handler checksagentRunStarted— since the agent had started (it made tool calls), it'strueemitUserTranscriptUpdate()— nobroadcastChatError()orbroadcastChatFinal()is called.catch()(which does callbroadcastChatError()) is never reached becauserun.tsreturned normally, not threwResult: The error payload sits in
deliveredRepliesbut is never broadcast. Connected clients (ACP bridges, etc.) never receive any error event.Expected Behavior
Clients should receive a
state: "error"chat event with the timeout error message, the same as other error scenarios.Suggested Fix
In the
.then()handler, whenagentRunStarted = true, checkdeliveredRepliesfor payloads withisError: true. If found, callbroadcastChatError()to notify connected clients:Environment
bde07ddb)glm-5-turbo(viaanthropic-messagesAPI)