Summary

• Fix Telegram direct-session fallback handling so a late dispatch/cleanup error does not send the generic visible failure reply after a final answer was already delivered, suppressed, or queued.
• Keep Telegram status reactions aligned with the same final-response boundary, so an already-successful visible turn is not reclassified as an error.
• Scope: this PR addresses the Telegram duplicate-fallback half of [Bug]: Spurious "Something went wrong" and Codex app-server failures in large Telegram direct sessions #87299 only; it does not claim to fix the separate Codex app-server client-closed incident.
• Why it matters / User impact: Telegram users should not see a successful final answer followed by a confusing generic failure message in the same direct chat.

Refs #87299

Root Cause

• Root cause: Telegram dispatch treated a later dispatchError as enough to send the generic failure fallback, even when the dispatch boundary already knew that a final response had reached the user or was queued for delivery.
• Why this is root-cause fix: The fallback decision now uses the Telegram dispatch boundary's delivery state plus the dispatcher queuedFinal result before considering dispatchError. The generic fallback still sends when no final response was delivered/suppressed/queued, but it is suppressed for the duplicate-message path after a successful final response.

Real behavior proof

• Behavior or issue addressed: Telegram direct-session users should receive the final answer without a second generic Something went wrong while processing your request. Please try again. message when a later dispatch/cleanup warning is recorded.
• Real environment tested:
  • Existing live Telegram smoke proof in the PR body was run on macOS Darwin 25.5.0 with Node 24.15.0, local OpenClaw dev gateway, worktree SHA a5505616a4, Telegram bot @moongpbot, and model deepseek/deepseek-v4-flash.
  • Current-head local verification was rerun on this daily-fix Linux worktree at a5505616a438b61f92700672083b4f1f9feac71e.
  • The Mantis Telegram Desktop Proof workflow also ran on current head and is the remaining external proof blocker.
• Exact steps or command run after this patch:

  # Existing live Telegram smoke proof already in the PR discussion/body:
  TOKEN=$(security find-generic-password -a openclaw-daily -s openclaw-telegram-bot-token -w)
  DEEPSEEK_KEY=$(security find-generic-password -a openclaw-daily -s openclaw-deepseek-api-key -w)
  export TELEGRAM_BOT_TOKEN="$TOKEN" DEEPSEEK_API_KEY="$DEEPSEEK_KEY"
  export OPENCLAW_HOME="/Users/zhangguiping/daily_pr_work/proofs/openclaw-issue-87299-evidence/home"
  export OPENCLAW_STATE_DIR="/Users/zhangguiping/daily_pr_work/proofs/openclaw-issue-87299-evidence/state"
  export OPENCLAW_CONFIG_PATH="/Users/zhangguiping/daily_pr_work/proofs/openclaw-issue-87299-evidence/state/openclaw.json"
  export OPENCLAW_DISABLE_BONJOUR=1 OPENCLAW_GATEWAY_PORT=19072
  node scripts/run-node.mjs --dev gateway
  # Sent Telegram DM to @moongpbot: please reply with exactly: openclaw proof ok
  
  # Current-head local verification rerun from TASK_WORKTREE:
  node scripts/run-vitest.mjs extensions/telegram/src/bot-message-dispatch.test.ts
  pnpm exec oxfmt --check --threads=1 extensions/telegram/src/bot-message-dispatch.ts extensions/telegram/src/bot-message-dispatch.test.ts
  npx oxlint --deny=warn --ignore-path=.oxlintignore extensions/telegram/src/bot-message-dispatch.ts extensions/telegram/src/bot-message-dispatch.test.ts
  git diff --check

• Evidence after fix:

  2026-06-04T02:09:10.779+08:00 [gateway] agent model: deepseek/deepseek-v4-flash (thinking=high, fast=off)
  2026-06-04T02:09:10.779+08:00 [gateway] http server listening (1 plugin: telegram; 1.5s)
  2026-06-04T02:09:10.880+08:00 [gateway] gateway ready
  2026-06-04T02:09:12.421+08:00 [telegram] [default] starting provider (@moongpbot)
  2026-06-04T02:09:13.820+08:00 [telegram][diag] isolated polling ingress started spool=/Users/zhangguiping/daily_pr_work/proofs/openclaw-issue-87299-evidence/state/telegram/ingress-spool-default
  2026-06-04T02:10:08.951+08:00 [telegram] Inbound message telegram:8903163841 -> @moongpbot (direct, 45 chars)
  2026-06-04T02:10:12.516+08:00 [telegram/send] telegram outbound send ok accountId=default chatId=8903163841 messageId=16 operation=sendMessage deliveryKind=text chunkCount=1
  Telegram observed reply: openclaw proof ok
  
  Current-head local verification:
  - bot-message-dispatch Vitest shard passed: 1 file, 105 tests.
  - oxfmt passed for the changed Telegram files.
  - oxlint passed for the changed Telegram files.
  - git diff --check passed with no output.
  

• Observed result after fix: The patched live Telegram gateway accepted a direct message and sent the requested final reply without an observed generic fallback afterward. The focused regression tests prove the forced late-dispatch-error-after-final path at the Telegram dispatch boundary.
• What was not tested: No live Telegram run in this environment forced the exact late-dispatch-error-after-final path. Normal live Telegram DM delivery was tested, and the forced late-error path is covered by dispatch-boundary regression tests.
• Known proof gap / external blocker: The live Telegram smoke proof covers normal direct-message delivery, not the exact forced path where a final reply is delivered and a later dispatch error is injected. The current-head Mantis Telegram Desktop Proof job failed because the proof agent reported that it could not find a supported runner/config input to trigger that late post-answer delivery error. This remaining exact-path live proof requires either a richer Telegram/Mantis harness that can force the late dispatch error, or maintainer acceptance of the dispatch-boundary regression tests plus live smoke proof.

Regression Test Plan

• Coverage level: focused Telegram dispatch regression test plus live Telegram smoke proof.
• Target test file: extensions/telegram/src/bot-message-dispatch.test.ts.
• Scenario locked in: a final visible Telegram reply is delivered and a later dispatcher error occurs; the chat receives only the final answer, no generic fallback, and the status reaction remains done.
• Additional scenario locked in: a final reply is already queued and the dispatcher warning callback fires; no generic fallback reply is emitted.
• Why this is the smallest reliable guardrail: the tests sit at the Telegram dispatch boundary that owns fallback delivery and directly assert the externally visible reply/status effects without changing provider, gateway, public config, schema, migration, or non-Telegram channel behavior.

Verification

• node scripts/run-vitest.mjs extensions/telegram/src/bot-message-dispatch.test.ts
  • Passed on current head: 1 Vitest shard, 1 file, 105 tests.
• pnpm exec oxfmt --check --threads=1 extensions/telegram/src/bot-message-dispatch.ts extensions/telegram/src/bot-message-dispatch.test.ts
  • Passed: all matched files use the correct format.
• npx oxlint --deny=warn --ignore-path=.oxlintignore extensions/telegram/src/bot-message-dispatch.ts extensions/telegram/src/bot-message-dispatch.test.ts
  • Passed with no diagnostics.
• git diff --check
  • Passed with no output.
• Remote current-head status for a5505616a438b61f92700672083b4f1f9feac71e:
  • daily-fix pr-final-status reported FAIL=1 PENDING=0 PASS=128 SKIPPED=27.
  • The only failing check is Run agentic native Telegram proof, attributed to the exact-path Mantis capture limitation above.

Review findings addressed

• RF-001: Not fixed by a code change; disclosed as an external proof gap. No redacted forced-path live Telegram artifact is available because the current Mantis/native proof setup could not trigger the late post-answer dispatch error.
• RF-002: Partially addressed with current-head local verification and explicit proof disclosure. The exact late-dispatch-error path remains covered by dispatch-boundary regression tests, not live forced Telegram capture.
• RF-003: Disclosed. The supplied live proof shows normal successful Telegram DM delivery; it does not show the exact delivered-final-plus-late-dispatch-error path.
• RF-004: Addressed by narrowing the PR body from closing syntax to Refs #87299 and stating that this PR covers only the Telegram duplicate-fallback half, not the Codex app-server client-closed half.
• RF-005: Maintainer judgment still requested. The chosen boundary is delivered, suppressed, or queued final reply because those are the dispatch owner facts that mean the user either already received or is scheduled to receive the final response.
• RF-006: Acknowledged. There is no remaining narrow automated code repair; the only remaining blocker is exact-path live proof or maintainer acceptance of the existing regression tests plus live smoke proof.

Merge risk

• Risk labels considered: merge-risk: 🚨 message-delivery.
• Risk explanation: This changes visible Telegram fallback/status behavior, so the blast radius is user-visible message delivery. The code scope is limited to Telegram dispatch fallback/status handling plus focused tests.
• Fix classification: Root-cause bug fix for the Telegram duplicate message-delivery path.
• Why acceptable: Existing fallback behavior remains for turns with no delivered, suppressed, or queued final response. The change only prevents a duplicate generic fallback after the dispatch boundary already has final-response evidence.
• Out of scope: This PR does not change Telegram auth/setup policy, provider routing, model routing, public config, schema, migration, protocol, fallback text, non-Telegram channel behavior, or Codex app-server behavior.
• Related open PR scan: daily-fix prework did not find a related open PR covering the same Telegram direct-session message-delivery contract.
• Patch quality notes: The production change stays inside the Telegram dispatch owner boundary and does not add fallback text, broad guards, dependencies, or unrelated behavior. The regression tests cover both delivered-final and queued-final duplicate-fallback cases.
• Maintainer-ready confidence: High for code and regression coverage; blocked for merge readiness until exact-path live proof is supplied or maintainers accept the disclosed proof gap.