fix(tui): dismiss watchdog notice when response actually arrives by RomneyDa · Pull Request #77375 · openclaw/openclaw

RomneyDa · 2026-05-04T15:02:06Z

Summary

The TUI streaming watchdog adds "This response is taking longer than expected. Send another message to continue." to the chat log after 30 s without a delta. When a chat delta or final then arrives — common for runs that were slow but not actually stuck — the notice persists next to the recovered response and contradicts what the user sees.

This change tracks the notice by runId and dismisses it from handleChatEvent whenever any further chat event for that run is processed, so the message disappears the moment the response continues. The watchdog's internal cleanup (activeChatRunId reset, status idle, deferred history reload) is unchanged, so genuinely stuck runs still show the notice and recover identically.

Implementation

src/tui/components/chat-log.ts — new addPendingSystem(runId, text) / dismissPendingSystem(runId) pair, keyed by runId (mirrors the existing pendingUsers map at addPendingUser / dropPendingUser). clearAll and dropComponentReferences updated.
src/tui/tui-event-handlers.ts — watchdog timer routes through addPendingSystem(runId, …), and handleChatEvent calls dismissPendingSystem(evt.runId) after early-return checks but before noteSessionRun, so any delta / final / aborted / error for the run drops a stale notice.
Tests cover the happy-path display, dismissal on a late delta, dismissal on a late final, and the chat-log component contract.

Refs TUI streaming indicator stays active long after response content finishes #67052 ("TUI streaming indicator stays active long after response content finishes") — same surface, adjacent UX bug; this PR addresses the user-visible notice rather than the streaming-status indicator timing, so TUI streaming indicator stays active long after response content finishes #67052 stays open.
Refs [Bug]: TUI: "streaming" status desyncs from actual run state #69081 (closed) — the watchdog desync issue whose tool/lifecycle proof-of-life fix already shipped on main.
Prior attempt fix(tui): raise streaming watchdog threshold to 120s and suppress false-positive warning #69026 by @jpruit20 raised the threshold to 120 s and suppressed the notice entirely; this PR is the narrower fix that keeps the warning useful for genuinely stuck runs. fix(tui): raise streaming watchdog threshold to 120s and suppress false-positive warning #69026 can be closed in favor of this once merged.

Verification

pnpm test src/tui/tui-event-handlers.test.ts src/tui/components/chat-log.test.ts — 61 passed (including 2 new dismissal tests + 2 new chat-log tests).
pnpm exec oxfmt --check --threads=1 src/tui/tui-event-handlers.ts src/tui/tui-event-handlers.test.ts src/tui/components/chat-log.ts src/tui/components/chat-log.test.ts CHANGELOG.md — clean.
node scripts/run-oxlint.mjs src/tui/tui-event-handlers.ts src/tui/tui-event-handlers.test.ts src/tui/components/chat-log.ts src/tui/components/chat-log.test.ts — 0 warnings, 0 errors.
pnpm check:changed — exit 0 (core + core-tests lanes selected).

Test plan

CI green
Manual TUI: trigger a run that exceeds 30 s without a delta, see the notice; let the run continue and confirm the notice disappears once a delta/final arrives
Manual TUI: trigger a genuinely stuck run (kill gateway mid-run); confirm the notice still appears and persists

clawsweeper · 2026-05-04T15:05:11Z

Codex review: needs maintainer review before merge.

Workflow note: Future ClawSweeper reviews update this same comment in place.

How this review workflow works

ClawSweeper keeps one durable marker-backed review comment per issue or PR.
Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
Maintainers can also comment @clawsweeper review to request a fresh review only.
Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

Summary
The PR changes the TUI chat log/watchdog to keep the timeout notice as a run-scoped pending system message, remove it when the same run later emits chat events, and adds focused tests plus a changelog entry.

Reproducibility: yes. from source inspection: on current main, a delta arms the watchdog, the timeout appends a normal system message, and a later same-run delta or final has no removal path. I did not run a live TUI scenario in this read-only review.

PR rating
Overall: 🐚 platinum hermit
Proof: 🌊 off-meta tidepool
Patch quality: 🐚 platinum hermit
Summary: Small focused patch with relevant source-level tests and no blocking findings, with real TUI validation still pending before merge.

Rank-up moves:

Capture or complete the quiet-run and genuinely-stuck-run TUI scenarios from the PR test plan before undrafting or merging.

What the crustacean ranks mean

🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
🌊 off-meta tidepool: rating does not apply to this item.

Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

Real behavior proof
Not applicable: The external-contributor proof gate does not apply to this maintainer-labeled MEMBER PR, though manual TUI validation is still the practical merge step.

Mantis proof suggestion
A short visible TUI proof would materially confirm that the notice appears after a quiet run and disappears when the same run resumes. A maintainer can ask Mantis to capture proof by posting a new PR comment that starts with the OpenClaw Mantis account mention, followed by:

visual task: verify in the TUI that the taking-longer notice appears after a quiet run, disappears on a late delta/final for the same run, and remains for a genuinely stuck run.

Risk before merge

Manual TUI validation is still pending, so the real quiet-run and genuinely-stuck-run user flows have not been shown in a live terminal session for this head.

Maintainer options:

Decide the mitigation before merge
Land this after maintainer-visible TUI proof confirms late delta/final events remove the stale notice while truly stuck runs still keep the warning; leave broader watchdog status and configurability work to the related issues.
Pause or close
Do not merge this PR until maintainers decide whether the risk is worth taking.

Next step before merge
There is no narrow automated repair to queue; the remaining action is maintainer validation of the live TUI scenarios, then undraft/merge or adjust based on that proof.

Security
Cleared: The diff only touches TUI state handling, focused tests, and changelog text; I found no concrete security or supply-chain concern.

Review details

Best possible solution:

Land this after maintainer-visible TUI proof confirms late delta/final events remove the stale notice while truly stuck runs still keep the warning; leave broader watchdog status and configurability work to the related issues.

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

Yes, from source inspection: on current main, a delta arms the watchdog, the timeout appends a normal system message, and a later same-run delta or final has no removal path. I did not run a live TUI scenario in this read-only review.

Is this the best way to solve the issue?

Yes, pending live proof. A run-scoped pending system notice is narrower than suppressing the watchdog or changing the timeout, and it keeps broader status/threshold behavior separate.

Label justifications:

P2: This is a normal-priority TUI UX bug fix with limited blast radius and focused tests, not a release-blocking runtime failure.
rating: 🐚 platinum hermit: Current PR rating is 🐚 platinum hermit because proof is 🌊 off-meta tidepool, patch quality is 🐚 platinum hermit, and Small focused patch with relevant source-level tests and no blocking findings, with real TUI validation still pending before merge.
status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Not applicable: The external-contributor proof gate does not apply to this maintainer-labeled MEMBER PR, though manual TUI validation is still the practical merge step.

What I checked:

Current main behavior: Current main appends the watchdog timeout notice through chatLog.addSystem, making it an ordinary chat-log entry with no run-scoped removal path. (src/tui/tui-event-handlers.ts:134, fad1c8a0711e)
Current late-event path: Current main processes later same-run chat events without any call that can remove a prior watchdog system notice. (src/tui/tui-event-handlers.ts:391, fad1c8a0711e)
PR implementation: The PR diff routes watchdog notices through addPendingSystem(runId, ...) and calls dismissPendingSystem(evt.runId) before normal chat-event processing continues. (src/tui/tui-event-handlers.ts:133, 1f55896e964f)
PR component contract: The PR adds a pendingSystemNotices map to ChatLog, clears it with chat-log reset, prunes references, and tests dismissal/replacement by run id. (src/tui/components/chat-log.ts:20, 1f55896e964f)
PR regression tests: The PR adds late-delta and late-final tests that assert the watchdog notice is dismissed after the timeout has fired. (src/tui/tui-event-handlers.test.ts:1401, 1f55896e964f)
Manual proof status: The PR body still has unchecked manual TUI scenarios, and the author commented that it is pending because both bug and fix have not been manually verified.

Likely related people:

xantorres: The watchdog code path appears to originate in f44ab20d4db5a556a83b6c082324be1dd3da3ac4, authored by Xan Torres and committed as the TUI streaming watchdog feature. (role: introduced watchdog behavior; confidence: high; commits: f44ab20d4db5; files: src/tui/tui-event-handlers.ts, src/tui/tui-event-handlers.test.ts)
Ayaan Zaidi: Ayaan Zaidi committed the original watchdog feature and authored the later active-run watchdog fix in 35252739307913f984beb84156f18285aa03320b. (role: recent watchdog maintainer and merger; confidence: high; commits: f44ab20d4db5, 352527393079; files: src/tui/tui-event-handlers.ts, src/tui/tui-event-handlers.test.ts)
Vincent Koc: Vincent Koc authored 51d6d7013f074c9a4aa0ffcd3d7083ec75f10537, which added the pending-user/busy-state chat-log pattern this PR mirrors. (role: adjacent chat-log state contributor; confidence: medium; commits: 51d6d7013f07; files: src/tui/components/chat-log.ts, src/tui/components/chat-log.test.ts)
Vignesh Natarajan: Vignesh Natarajan authored 1cc2263578e90bffe5ca189aca97b2f0b370075c, which added chat-log pruning and reference cleanup that the PR extends for pending system notices. (role: adjacent chat-log maintainer; confidence: medium; commits: 1cc2263578e9; files: src/tui/components/chat-log.ts, src/tui/components/chat-log.test.ts)

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

RomneyDa · 2026-05-18T23:57:50Z

pending because haven't manually verified both bug and fix

clawsweeper · 2026-05-21T23:29:45Z

ClawSweeper PR egg

✨ Hatched: 🥚 common Clockwork Proofling

Hatch command

Comment @clawsweeper hatch when this PR is hatchable.

Hatchability rules:

Merged PRs are hatchable.
Open PRs are hatchable when they are status: 👀 ready for maintainer look, status: 🚀 automerge armed, or labeled clawsweeper:automerge.
Closed unmerged PRs are hatchable only when one of those hatchable labels is still present in the durable record.

Rarity: 🥚 common.
Trait: sniffs out flaky tests.
Image traits: location release reef; accessory commit compass; palette charcoal, cyan, and signal green; mood focused; pose sitting proudly on a smooth stone; shell soft speckled shell; lighting gentle morning glow; background soft code-shaped tiles.
Share on X: post this hatch
Copy: My PR egg hatched a 🥚 common Clockwork Proofling in ClawSweeper.

What is this egg doing here?

Eggs appear after the PR passes real-behavior proof. It is here for vibes, not verdicts: it does not change labels, ratings, merge decisions, or automation.
The shell reacts to review momentum: open follow-up work warms it up, re-review makes it wobble, and a clean final review lets it hatch.
Hatchability usually comes from sufficient real-behavior proof, no blocking P0/P1/P2 findings, no security attention needed, and clean correctness. A merged PR is already final, so merge makes the egg hatchable independently.
The hatch is seeded from this repository and PR number, so the same PR keeps the same creature; the reviewed head SHA can only change safe visual details.
Rarity is just collectible sparkle: 🥚 common, 🌱 uncommon, 💎 rare, ✨ glimmer, and 🌈 legendary.

steipete · 2026-05-22T18:59:51Z

I’m confident this is a real, low-risk fix after checking it against current main and the PR branch.

Proof:

On current main, a real-timer TUI scenario reproduces the bug: the watchdog notice appears after the timeout and stays visible even after a late delta and the final response arrive.
On this PR branch, the same scenario behaves correctly: the notice appears after the timeout, disappears when the late delta arrives, and stays gone after the final response.
Focused regression proof passed: pnpm test src/tui/components/chat-log.test.ts src/tui/tui-event-handlers.test.ts with 64 tests passing.
The fix is TUI-local: it tracks watchdog notices as pending system entries by run id, then dismisses only that run’s pending notice when a chat event resumes or finalizes the run. No plugin/SDK/provider boundary, no dependency change, no behavior change outside the chat log/event-handler surface.

I’m rebasing onto latest main before landing so the final merge is against the current tree. Thanks for the focused fix, @RomneyDa.

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.

chatgpt-codex-connector

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 032b4abb2d

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

chatgpt-codex-connector · 2026-05-22T19:06:30Z

    if (reconnectPendingRunId === evt.runId) {
      reconnectPendingRunId = null;
    }
+    chatLog.dismissPendingSystem(evt.runId);


Render immediately after dismissing watchdog notice

handleChatEvent now dismisses the watchdog message before delta processing, but delta events that produce no visible text still hit return at if (!displayText). In that path (e.g., first tool-call/thinking-only delta, which this function explicitly expects), no tui.requestRender() runs, so the notice is removed from state but can remain on screen until a later event triggers a render. This means the new behavior can still show a stale “taking longer than expected” notice after the run has resumed.

Useful? React with 👍 / 👎.

…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 size: S maintainer Maintainer-authored PR labels May 4, 2026

RomneyDa marked this pull request as draft May 4, 2026 20:40

This was referenced May 13, 2026

Feature Request: Add /watchdog command and suppress duplicate watchdog warnings per run #69978

Closed

[Bug]: TUI stream watchdog marks quiet active runs idle in 2026.5.4 #78360

Closed

RomneyDa force-pushed the fix/tui-watchdog-notice-dismiss branch from 29294ca to 97e4e18 Compare May 18, 2026 03:29

RomneyDa force-pushed the fix/tui-watchdog-notice-dismiss branch from 18fa9d1 to 1cac261 Compare May 18, 2026 20:26

RomneyDa force-pushed the fix/tui-watchdog-notice-dismiss branch from 1cac261 to 1f55896 Compare May 21, 2026 23:23

RomneyDa and others added 2 commits May 22, 2026 19:59

fix(tui): adapt pending notice to repeatable system entries

032b4ab

steipete force-pushed the fix/tui-watchdog-notice-dismiss branch from 1f55896 to 032b4ab Compare May 22, 2026 19:01

steipete marked this pull request as ready for review May 22, 2026 19:02

steipete merged commit b741ddb into main May 22, 2026
44 checks passed

steipete deleted the fix/tui-watchdog-notice-dismiss branch May 22, 2026 19:02

chatgpt-codex-connector Bot reviewed May 22, 2026

View reviewed changes

github-actions Bot mentioned this pull request May 22, 2026

📡 Upstream Digest — 2026-05-22 19:24 UTC curtismercier/openclaw-mods#918

Open

clawsweeper Bot mentioned this pull request May 23, 2026

Feature: Activity panel / tool call observer mode #12831

Closed

clawsweeper Bot mentioned this pull request Jun 18, 2026

feat(tui,cli-runner): expose streamingWatchdogMs config + bump watchdog defaults #79997

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

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

fix(tui): dismiss watchdog notice when response actually arrives#77375
steipete merged 2 commits into
mainfrom
fix/tui-watchdog-notice-dismiss

RomneyDa commented May 4, 2026

Uh oh!

clawsweeper Bot commented May 4, 2026 •

edited

Loading

Uh oh!

RomneyDa commented May 18, 2026 •

edited

Loading

Uh oh!

clawsweeper Bot commented May 21, 2026

Uh oh!

steipete commented May 22, 2026

Uh oh!

Uh oh!

chatgpt-codex-connector Bot left a comment

Uh oh!

chatgpt-codex-connector Bot May 22, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Uh oh!

Conversation

RomneyDa commented May 4, 2026

Summary

Implementation

Related

Verification

Test plan

Uh oh!

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

Uh oh!

Uh oh!

RomneyDa commented May 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

clawsweeper Bot commented May 21, 2026

Hatch command

Uh oh!

steipete commented May 22, 2026

Uh oh!

Uh oh!

chatgpt-codex-connector Bot left a comment

Choose a reason for hiding this comment

💡 Codex Review

Uh oh!

chatgpt-codex-connector Bot May 22, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

clawsweeper Bot commented May 4, 2026 •

edited

Loading

RomneyDa commented May 18, 2026 •

edited

Loading