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#69026jpruit20 wants to merge 1 commit intoopenclaw:mainfrom
Conversation
…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 SummaryThis 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 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 Confidence Score: 5/5Safe 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 AIThis 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 |
| /* 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. */ |
There was a problem hiding this comment.
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!
|
Codex review: found issues before merge. Summary Reproducibility: yes. from source inspection. Current fake-timer tests send a chat delta, advance past Next step before merge Security Review findings
Review detailsBest possible solution: Keep the current proof-of-life and reconnect fixes, then choose a maintainable UX for normal watchdog expirations: softer/deduped feedback or an explicit user-facing threshold setting rather than silently hiding all events by default. Do we have a high-confidence way to reproduce the issue? Yes from source inspection. Current fake-timer tests send a chat delta, advance past Is this the best way to solve the issue? Unclear. The patch is narrow, but complete suppression is a maintainer UX choice because it removes diagnostics for genuine silent drops; a softer deduped warning or explicit configuration may be safer. Full review comments:
Overall correctness: patch is correct Acceptance criteria:
What I checked:
Likely related people:
Remaining risk / open question:
Codex review notes: model gpt-5.5, reasoning high; reviewed against 9a49d143c819. |
Problem
The TUI streaming watchdog is set to 30 seconds, which triggers false-positive warnings during healthy long-running agent turns:
This fires regularly during:
The alarming "backend may have dropped this run" message causes unnecessary user confusion.
Changes
src/tui/tui-event-handlers.tsDEFAULT_STREAMING_WATCHDOG_MSchanged from30_000(30s) →120_000(120s)chatLog.addSystem()call replaced with a comment — warning suppressed entirelyWhat's preserved
activeChatRunIdcleared,activityStatusset toidle,tui.requestRender()calledcontext.streamingWatchdogMsoverride still works for custom valuesstreamingWatchdogMs: 0still disables the watchdog entirelysrc/tui/tui-event-handlers.test.tsRationale
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.