fix(typing): add markDispatchIdle safety net to main reply pipeline by Sid-Qin · Pull Request #27250 · openclaw/openclaw

Sid-Qin · 2026-02-26T06:19:08Z

Summary

Problem: Telegram typing indicator ("typing...") persists indefinitely after agent runs complete. At least 7 separate issue reports in the last 2 hours describe the same symptom — the typing keepalive loop is never stopped because markDispatchIdle() never fires.
Why it matters: This is the fix: add @lid format support and allowFrom wildcard handling #1 reported bug today. Every Telegram user is affected. The only workaround is openclaw gateway restart, which is disruptive and temporary.
Root cause: The typing controller requires two signals to stop: markRunComplete() AND markDispatchIdle(). The followup runner was fixed in fix(typing): call markDispatchIdle in followup runner to prevent stuck indicator #26881 to call both in its finally block, but the main reply pipeline (agent-runner.ts) only calls markRunComplete(), relying on the dispatcher's onIdle callback for the second signal. If the dispatcher exits early, errors, or the reply path doesn't go through it cleanly, markDispatchIdle() is never called.
What changed: src/auto-reply/reply/agent-runner.ts — Added typing.markDispatchIdle() as a safety net in the finally block, identical to the fix(typing): call markDispatchIdle in followup runner to prevent stuck indicator #26881 followup runner fix.
What did NOT change: Typing controller logic, dispatcher behavior, followup runner, keepalive interval, TTL.

Change Type (select all)

Scope (select all touched areas)

Linked Issue/PR

Closes bug(typing): main reply pipeline missing markDispatchIdle() — same pattern as #26881 but different code path #27172
Closes bug(telegram): typing indicator can stay stuck after replies (v2026.2.24) #27174
Closes [Bug]: Telegram "typing..." indicator persists indefinitely after agent run completes #27177
Closes bug(telegram): typing indicator persists indefinitely when bot is idle #27219
Closes Telegram typing indicator persists indefinitely — run end events never emitted #27226
Related: fix(typing): call markDispatchIdle in followup runner to prevent stuck indicator #26881 (same pattern, followup runner)
Related: v2026.2.24: Spurious typing indicators flash in DMs (multiple bots) #27156, [Bug]: change embedding model causing infinite typing status in Telegram #27143, Bug: 无限'输入中'状态 (双 Gateway 部署 + Telegram) #27183 (same symptom, different reports)

User-visible / Behavior Changes

Telegram typing indicator now reliably stops when the agent run completes
No more "stuck typing" after normal inbound replies

Security Impact (required)

New permissions/capabilities? No
Secrets/tokens handling changed? No
New/changed network calls? No
Command/tool execution surface changed? No
Data access scope changed? No

Repro + Verification

Environment

OS: macOS 15.4
Runtime: Node 22
Integration/channel: Telegram

Steps

Send a message to the bot on Telegram
Wait for the reply to complete
Observe the typing indicator

Expected

Typing indicator stops when reply is sent

Actual

Before fix: Typing indicator persists indefinitely (until 2-min TTL or gateway restart)
After fix: Typing indicator stops as soon as the run completes

Evidence

Tests: 76 passed (76) — src/auto-reply/reply/agent-runner*.test.ts (5 test files)

The fix is the same one-liner pattern proven in #26881 for the followup runner. Calling markDispatchIdle() twice is harmless — cleanup() is guarded by the active flag, and maybeStopOnIdle() only fires cleanup when both runComplete and dispatchIdle are true.

Human Verification (required)

Verified scenarios: main reply pipeline finally block now matches followup runner pattern
Edge cases checked: double-call is safe (guarded by active flag), dispatcher onIdle still works normally
What I did not verify: Live Telegram typing indicator behavior

Compatibility / Migration

Backward compatible? Yes
Config/env changes? No
Migration needed? No

Failure Recovery (if this breaks)

How to disable/revert: Revert this commit; typing indicator will rely solely on dispatcher's onIdle callback
Files/config to restore: src/auto-reply/reply/agent-runner.ts

Risks and Mitigations

None — this is a defensive safety net. The same pattern is already proven in production via #26881 for the followup runner. The typing controller's cleanup() is idempotent.

The typing controller requires both markRunComplete() and markDispatchIdle() to stop the keepalive loop. The followup runner was fixed in openclaw#26881 to call both signals, but the main reply pipeline in agent-runner.ts only calls markRunComplete() in its finally block, relying on the dispatcher's onIdle callback for the second signal. If the dispatcher exits early, errors, or the reply path doesn't go through it cleanly, markDispatchIdle() is never called and the Telegram typing indicator persists indefinitely. Add the same safety-net pattern from openclaw#26881: call typing.markDispatchIdle() in the finally block. This is harmless when the dispatcher fires normally — cleanup() is guarded by the active flag — but prevents stuck indicators on every edge case. Closes openclaw#27172 Closes openclaw#27174 Closes openclaw#27177 Closes openclaw#27219 Closes openclaw#27226

greptile-apps · 2026-02-26T06:21:19Z

Greptile Summary

Adds defensive safety net to prevent stuck Telegram typing indicators by ensuring both cleanup signals (markRunComplete() and markDispatchIdle()) are called in the main reply pipeline's finally block.

Root cause: Typing controller requires two signals to stop. The dispatcher's onIdle callback normally fires markDispatchIdle(), but if the dispatcher exits early or errors, the second signal never fires and typing persists indefinitely.
Fix: Mirrors the proven pattern from fix(typing): call markDispatchIdle in followup runner to prevent stuck indicator #26881 (followup runner) by calling typing.markDispatchIdle() in the finally block as a safety net.
Safety: The cleanup() function is guarded by a sealed flag, making duplicate calls harmless. The typing controller's maybeStopOnIdle() only triggers cleanup when both flags are set.
Impact: Resolves the fix: add @lid format support and allowFrom wildcard handling #1 reported bug affecting all Telegram users (7+ issue reports in 2 hours).
Testing: All 76 agent-runner tests pass.

Confidence Score: 5/5

This PR is safe to merge with minimal risk.
Single-line fix following a proven pattern already in production (PR fix(typing): call markDispatchIdle in followup runner to prevent stuck indicator #26881), with idempotent cleanup guarantees. All tests pass and the change only adds a safety net for edge cases without altering normal operation.
No files require special attention.

_{Last reviewed commit: 7b2239e}

@Sid-Qin

@Sid-Qin) Co-authored-by: Sid Qin <s3734389@gmail.com>

steipete · 2026-02-26T11:36:29Z

Landed on main via commit 199ef9f8e.

What was landed from this PR:

Added typing.markDispatchIdle() safety-net in runReplyAgent finalization so typing cleanup still runs when dispatcher onIdle does not fire.
Added changelog entry with attribution in 2026.2.26 (Unreleased).

Attribution:

Original PR commit: 7b2239ebe583c4e516ad8324b646e65dfc69d138
Landed commit: 199ef9f8e

Validation run before landing (/landpr flow):

pnpm lint: pass
pnpm build: pass
pnpm test: fail on pre-existing unrelated test (extensions/msteams/src/messenger.test.ts silent-prefix assertion), not in touched files.

Thanks @Sid-Qin for the fix.

@Sid-Qin