fix(tui): raise streaming watchdog threshold to 120s and suppress false-positive warning by jpruit20 · Pull Request #69026 · openclaw/openclaw

jpruit20 · 2026-04-19T16:53:07Z

Problem

The TUI streaming watchdog is set to 30 seconds, which triggers false-positive warnings during healthy long-running agent turns:

streaming watchdog: no stream updates for 30s; resetting status. The backend may have dropped this run silently — send a new message to resync.

This fires regularly during:

Tool calls that take >30s (browser automation, file operations, code generation)
Sub-agent work
Long Claude thinking turns
Any agent turn where the backend is working but hasn't sent a stream delta

The alarming "backend may have dropped this run" message causes unnecessary user confusion.

Changes

`src/tui/tui-event-handlers.ts`

Threshold: DEFAULT_STREAMING_WATCHDOG_MS changed from 30_000 (30s) → 120_000 (120s)
Message: chatLog.addSystem() call replaced with a comment — warning suppressed entirely

What's preserved

Internal reset behavior: activeChatRunId cleared, activityStatus set to idle, tui.requestRender() called
The context.streamingWatchdogMs override still works for custom values
Setting streamingWatchdogMs: 0 still disables the watchdog entirely

`src/tui/tui-event-handlers.test.ts`

Updated two test assertions to match the suppressed message behavior
All other watchdog tests unchanged (timer behavior, disposal, run isolation)

Rationale

The watchdog's internal reset (clearing stale run state, returning status to idle) is valuable. But the user-facing warning creates more confusion than it solves — users can always send a new message to resync if something is truly stuck, and the 120s threshold means the reset only fires for genuinely stalled connections rather than healthy long operations.

…se-positive warning The TUI streaming watchdog was set to 30 seconds, which triggers false-positive 'no stream updates' warnings during healthy long-running agent turns (tool calls, sub-agent work, code generation, browser automation). The alarming message ('backend may have dropped this run') caused unnecessary user confusion. Changes: - Raise DEFAULT_STREAMING_WATCHDOG_MS from 30s to 120s - Suppress the user-visible chatLog.addSystem() warning - Internal reset behavior is fully preserved (activeChatRunId cleared, activityStatus set to idle, render requested) - The override context.streamingWatchdogMs still works for custom values - Update tests to match suppressed message behavior

greptile-apps · 2026-04-19T16:54:31Z

Greptile Summary

This PR raises the streaming watchdog timeout from 30 s to 120 s and suppresses the user-visible warning entirely, keeping only the internal state reset (clearing activeChatRunId, setting status to idle, triggering a render). Tests are correctly updated to assert that chatLog.addSystem is no longer called.

The internal mechanics are sound, but completely removing the user-facing message means a genuine silent connection drop after 120 s will also produce no feedback — users will only see the status quietly change to idle with no explanation of why or what to do next.

Confidence Score: 5/5

Safe to merge; the change is intentional and technically correct, with properly updated tests.

All remaining feedback is P2 (UX/product preference around message suppression vs. softer messaging). No correctness, data-integrity, or security issues introduced.

src/tui/tui-event-handlers.ts — watchdog silent-reset UX tradeoff worth discussing before shipping.

Prompt To Fix All With AI

This is a comment left during a code review.
Path: src/tui/tui-event-handlers.ts
Line: 106-110

Comment:
**Silent reset trades one UX problem for another**

When the watchdog fires after a genuine connection drop (not just a long tool call), the status silently flips from `streaming` → `idle` with zero indication to the user. They won't know whether their request completed normally or was dropped, and they have no prompt to resync. A softer, lower-anxiety message (e.g., `"Agent turn is taking longer than expected — send a new message if you'd like to resync."`) would avoid the false-positive alarm tone while still surfacing the event. Alternatively, a debug-level log (if the codebase has a logger) would at least preserve diagnosability without any user noise.

How can I resolve this? If you propose a fix, please make it concise.

_{Reviews (1): Last reviewed commit: "fix(tui): raise streaming watchdog thres..." | Re-trigger Greptile}

greptile-apps · 2026-04-19T16:54:35Z

+      /* Watchdog fires silently — the internal reset (clearing activeChatRunId,
+         setting status idle) still happens, but the user-visible warning is
+         suppressed to avoid false-positive noise during long-running agent
+         turns (tool calls, sub-agent work, code generation).  The user can
+         always send a new message to resync if something is truly stuck. */


Silent reset trades one UX problem for another

When the watchdog fires after a genuine connection drop (not just a long tool call), the status silently flips from streaming → idle with zero indication to the user. They won't know whether their request completed normally or was dropped, and they have no prompt to resync. A softer, lower-anxiety message (e.g., "Agent turn is taking longer than expected — send a new message if you'd like to resync.") would avoid the false-positive alarm tone while still surfacing the event. Alternatively, a debug-level log (if the codebase has a logger) would at least preserve diagnosability without any user noise.

Prompt To Fix With AI

This is a comment left during a code review. Path: src/tui/tui-event-handlers.ts Line: 106-110 Comment: **Silent reset trades one UX problem for another** When the watchdog fires after a genuine connection drop (not just a long tool call), the status silently flips from `streaming` → `idle` with zero indication to the user. They won't know whether their request completed normally or was dropped, and they have no prompt to resync. A softer, lower-anxiety message (e.g., `"Agent turn is taking longer than expected — send a new message if you'd like to resync."`) would avoid the false-positive alarm tone while still surfacing the event. Alternatively, a debug-level log (if the codebase has a logger) would at least preserve diagnosability without any user noise. How can I resolve this? If you propose a fix, please make it concise.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

clawsweeper · 2026-04-28T22:18:27Z

Thanks for the context here. I swept through the related work, and this is now duplicate or superseded.

Close as superseded: current main already replaced the alarming watchdog wording and added proof-of-life/reconnect recovery, while the remaining timeout, dedupe, and quiet-run UX work is tracked by narrower open watchdog items. The branch’s unique silent-reset approach would remove useful feedback for genuine silent drops.

So I’m closing this here and keeping the remaining discussion on the canonical linked item.

Review details

Best possible solution:

Keep the visible low-anxiety watchdog cue, preserve the shipped proof-of-life and reconnect recovery, and route timeout control or notice dismissal through the narrower canonical watchdog issues and PRs.

Do we have a high-confidence way to reproduce the issue?

Yes, source-reproducible. The existing fake-timer harness demonstrates the watchdog path by sending a delta, advancing beyond streamingWatchdogMs, and observing the idle reset plus system notice; I did not run a live TUI session in this read-only review.

Is this the best way to solve the issue?

No. Suppressing the notice entirely is not the best fix because the watchdog also covers genuine silent drops, while current main already softened the wording and related open work tracks threshold/config and dismissible-notice behavior.

Security review:

Security review cleared: The diff only changes TUI watchdog TypeScript and tests, with no dependency, workflow, secret, package, or artifact-handling changes.

What I checked:

Current main keeps a visible low-anxiety watchdog notice: Current main still defaults DEFAULT_STREAMING_WATCHDOG_MS to 30 seconds and sends STREAMING_WATCHDOG_USER_MESSAGE when the normal watchdog clears an active run, so it does not implement this PR's silent reset. (src/tui/tui-event-handlers.ts:51, c3e5d85ce1df)
Current tests assert the visible notice path: The focused fake-timer watchdog test advances past the watchdog window, expects activeChatRunId to clear, and expects the softer timeout message to be logged. (src/tui/tui-event-handlers.test.ts:986, c3e5d85ce1df)
PR diff removes the only stuck-run cue: The proposed patch replaces the chatLog.addSystem(...) call with a comment, so a genuine silent drop would clear state and flip idle with no chat-log explanation. (src/tui/tui-event-handlers.ts:103, 0eba92010fe1)
Soft-copy fix already merged: Merged [codex] TUI: simplify stale response notice #77120 replaced the old backend/streaming wording with plain user-facing copy while preserving watchdog recovery behavior. (CHANGELOG.md:1287, 1df6226d907d)
Proof-of-life watchdog recovery already merged: Merged fix(tui): resync streaming watchdog after reconnect #74224 treats active tool and lifecycle events as watchdog proof-of-life, pauses during disconnect, and reloads history for reconnect-stale runs. (src/tui/tui-event-handlers.ts:478, d4e52f454255)
Remaining timeout control is tracked elsewhere: Open Feature Request: Configurable streaming watchdog timeout threshold #68596 tracks configurable watchdog threshold work, and open feat(tui,cli-runner): expose streamingWatchdogMs config + bump watchdog defaults #79997 attempts the config/default wiring.

Likely related people:

xantorres: Authored the merged TUI streaming watchdog work in fix(stability): session skills snapshot, tool-loop guard, TUI watchdog, LM Studio preload backoff #67401, including the 30-second default, user-visible reset note, and internal streamingWatchdogMs seam. (role: introduced watchdog behavior; confidence: high; commits: 55b8f638e1a9, 352527393079; files: src/tui/tui-event-handlers.ts, src/tui/tui-event-handlers.test.ts, CHANGELOG.md)
rogerdigital: Authored the merged reconnect/tool/lifecycle proof-of-life watchdog recovery that current follow-up work must preserve. (role: recent adjacent contributor; confidence: high; commits: 42a1214eb0d9, d33b66cb8f43, 215f687d69e1; files: src/tui/tui-event-handlers.ts, src/tui/tui-event-handlers.test.ts, src/tui/tui.ts)
davemorin: Authored the merged change that replaced the old internal watchdog wording with the current softer notice text this PR would remove. (role: recent user-facing copy contributor; confidence: high; commits: dd6223293132, 1df6226d907d; files: src/tui/tui-event-handlers.ts, src/tui/tui-event-handlers.test.ts, CHANGELOG.md)
vincentkoc: Recently handled stale streaming and orphaned-final recovery paths in the same TUI handler/test surface. (role: recent adjacent contributor; confidence: medium; commits: 551e6687742c, 1c43ca6e261b, b182228a9676; files: src/tui/tui-event-handlers.ts, src/tui/tui-event-handlers.test.ts)

Codex review notes: model gpt-5.5, reasoning high; reviewed against c3e5d85ce1df.

The streaming watchdog renders 'This response is taking longer than expected. Send another message to continue.' after 30s without a chat delta. If a delta or final then arrives — common for runs that are slow but not stuck — the notice stays in the log alongside the recovered response and contradicts what the user sees. Track the notice by runId in the chat log via a new `addPendingSystem` + `dismissPendingSystem` pair (mirroring the existing pendingUsers pattern) and dismiss it from `handleChatEvent` whenever any further chat event for that run is processed. The watchdog's internal cleanup (`activeChatRunId` reset, status idle, history reload) is unchanged. Refs #67052, #69081 (closed). Prior attempt #69026 raised the threshold and suppressed the notice entirely; this is the narrower fix that keeps the warning useful for genuinely stuck runs.

) * fix(tui): dismiss watchdog notice when response actually arrives The streaming watchdog renders 'This response is taking longer than expected. Send another message to continue.' after 30s without a chat delta. If a delta or final then arrives — common for runs that are slow but not stuck — the notice stays in the log alongside the recovered response and contradicts what the user sees. Track the notice by runId in the chat log via a new `addPendingSystem` + `dismissPendingSystem` pair (mirroring the existing pendingUsers pattern) and dismiss it from `handleChatEvent` whenever any further chat event for that run is processed. The watchdog's internal cleanup (`activeChatRunId` reset, status idle, history reload) is unchanged. Refs #67052, #69081 (closed). Prior attempt #69026 raised the threshold and suppressed the notice entirely; this is the narrower fix that keeps the warning useful for genuinely stuck runs. * fix(tui): adapt pending notice to repeatable system entries --------- Co-authored-by: Peter Steinberger <[email protected]>

…nclaw#77375) * fix(tui): dismiss watchdog notice when response actually arrives The streaming watchdog renders 'This response is taking longer than expected. Send another message to continue.' after 30s without a chat delta. If a delta or final then arrives — common for runs that are slow but not stuck — the notice stays in the log alongside the recovered response and contradicts what the user sees. Track the notice by runId in the chat log via a new `addPendingSystem` + `dismissPendingSystem` pair (mirroring the existing pendingUsers pattern) and dismiss it from `handleChatEvent` whenever any further chat event for that run is processed. The watchdog's internal cleanup (`activeChatRunId` reset, status idle, history reload) is unchanged. Refs openclaw#67052, openclaw#69081 (closed). Prior attempt openclaw#69026 raised the threshold and suppressed the notice entirely; this is the narrower fix that keeps the warning useful for genuinely stuck runs. * fix(tui): adapt pending notice to repeatable system entries --------- Co-authored-by: Peter Steinberger <[email protected]>

openclaw-barnacle Bot added the size: XS label Apr 19, 2026

greptile-apps Bot reviewed Apr 19, 2026

View reviewed changes

vincentkoc mentioned this pull request Apr 26, 2026

fix(tui): clear stale streaming after orphaned finals #72389

Merged

clawsweeper Bot mentioned this pull request Apr 28, 2026

Feature Request: Configurable streaming watchdog timeout threshold #68596

Open

RomneyDa mentioned this pull request May 4, 2026

fix(tui): dismiss watchdog notice when response actually arrives #77375

Merged

3 tasks

clawsweeper Bot closed this May 13, 2026

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

fix(tui): raise streaming watchdog threshold to 120s and suppress false-positive warning#69026

fix(tui): raise streaming watchdog threshold to 120s and suppress false-positive warning#69026
jpruit20 wants to merge 1 commit into
openclaw:mainfrom
jpruit20:fix/tui-streaming-watchdog-threshold

jpruit20 commented Apr 19, 2026

Uh oh!

greptile-apps Bot commented Apr 19, 2026

Uh oh!

greptile-apps Bot Apr 19, 2026

Uh oh!

clawsweeper Bot commented Apr 28, 2026 •

edited

Loading

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Uh oh!

Conversation

jpruit20 commented Apr 19, 2026

Problem

Changes

src/tui/tui-event-handlers.ts

What's preserved

src/tui/tui-event-handlers.test.ts

Rationale

Uh oh!

greptile-apps Bot commented Apr 19, 2026

Greptile Summary

Confidence Score: 5/5

Uh oh!

greptile-apps Bot Apr 19, 2026

Choose a reason for hiding this comment

Uh oh!

clawsweeper Bot commented Apr 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

`src/tui/tui-event-handlers.ts`

`src/tui/tui-event-handlers.test.ts`

clawsweeper Bot commented Apr 28, 2026 •

edited

Loading