Skip to content

fix(telegram): suppress failure fallback when source delivery is message-tool-only#90114

Closed
openperf wants to merge 1 commit into
openclaw:mainfrom
openperf:fix/90091-telegram-message-tool-fallback
Closed

fix(telegram): suppress failure fallback when source delivery is message-tool-only#90114
openperf wants to merge 1 commit into
openclaw:mainfrom
openperf:fix/90091-telegram-message-tool-fallback

Conversation

@openperf

@openperf openperf commented Jun 4, 2026 •
edited
Loading

Copy link
Copy Markdown
Member

Summary

  • Problem: Issue Telegram message-tool-only turns can still emit empty-response fallback via skipped delivery lane #90091 reports that Telegram group turns using message_tool_only source delivery still emit a spurious "No response generated. Please try again." fallback message after the agent already delivered the visible reply via the message tool.
  • Root Cause: shouldSendFailureFallback in bot-message-dispatch.ts is gated on !isRoomEvent but not on !suppressSilentReplyFallback. suppressSilentReplyFallback is set to true when dispatchResult.sourceReplyDeliveryMode === "message_tool_only" — but dispatch-from-config.ts can resolve sourceReplyDeliveryMode to "message_tool_only" via config (e.g. visibleReplies === "message_tool") even for user_request events where isRoomEvent = false. When the message tool delivers the visible reply and the main reply lane is skipped with reason "empty" (skippedNonSilent = 1), the failure fallback fires.
  • Fix: Add !suppressSilentReplyFallback to the shouldSendFailureFallback condition. The sibling silent-fallback branch at the same site already carries this guard; this aligns the failure-fallback branch with the same invariant.
  • What changed: bot-message-dispatch.ts — one-line guard addition; bot-message-dispatch.test.ts — one regression test covering the non-room-event group turn with non-silent skip + message_tool_only dispatch result.
  • What did NOT change: Config surface unchanged. Plugin surface unchanged. Gateway protocol unchanged.

Reproduction

  1. Configure a Telegram group with visibleReplies: "message_tool" (or equivalent global/agent-level policy)
  2. Send a message that triggers a user_request event (e.g. mention the bot)
  3. The agent delivers a reply via message(action="send") and returns NO_REPLY as the final text
  4. The main reply lane is skipped with reason "empty" (skippedNonSilent = 1)
  5. Before this PR: Telegram sends "No response generated. Please try again." as a delivery-mirror fallback, even though the agent already replied via message tool
  6. After this PR: No fallback message is sent; the turn completes cleanly

Real behavior proof

Behavior addressed (#90091): after a message_tool_only turn where the message tool delivered the visible reply, Telegram no longer emits a spurious "No response generated. Please try again." fallback from the failure-fallback branch

Real environment tested (source inspection; no live Telegram replay performed): dispatch-from-config.ts confirmed to resolve sourceReplyDeliveryMode === "message_tool_only" independently of isRoomEvent when visibleReplies === "message_tool" via config; bot-message-dispatch.ts confirmed to set suppressSilentReplyFallback = true from that dispatch result while leaving isRoomEvent = false; reporter's session transcript (2026-06-04T00:07:02.309Z delivery-mirror messages) provided live evidence of the failure

Exact steps or command run after this patch: node scripts/run-vitest.mjs extensions/telegram/src/bot-message-dispatch.test.ts; git diff --check; node scripts/run-oxlint.mjs extensions/telegram/src/bot-message-dispatch.ts extensions/telegram/src/bot-message-dispatch.test.ts

Evidence after fix (Vitest output for the touched test file):

 Test Files  1 passed (1)
       Tests  104 passed (104)
    Duration  25.66s

The new test does not send failure fallback when source delivery is message-tool-only and reply lane is non-silently skipped calls dispatcherOptions.onSkip with reason: "empty" (setting skippedNonSilent = 1) and returns sourceReplyDeliveryMode: "message_tool_only", then asserts deliverReplies is not called. Without the fix the test fails because shouldSendFailureFallback evaluates to true.

Observed result after fix: deliverReplies not called when suppressSilentReplyFallback = true regardless of isRoomEvent; the failure-fallback branch is now aligned with the sibling silent-fallback branch which already carried this guard

What was not tested: live Telegram group replay with a configured visibleReplies: "message_tool" policy end-to-end; reporter's session transcript confirmed the source path

Risk / Mitigation

  • Risk: Suppressing the failure fallback for a message_tool_only turn where the message tool itself also failed. Mitigation: suppressSilentReplyFallback is only true when the dispatch result reports message_tool_only — meaning the dispatch layer decided the turn was handled by the message tool; the sibling silent-fallback branch carries the same guard with the same invariant.
  • Risk: A message_tool_only turn where delivery genuinely failed could silently swallow the error. Mitigation: dispatchError still fires the fallback unconditionally before suppressSilentReplyFallback is evaluated; only the non-error skipped/failed delivery-summary path is suppressed.

Change Type (select all)

  • Bug fix

Scope (select all touched areas)

  • Telegram

Linked Issue/PR

Fixes #90091

@openclaw-barnacle openclaw-barnacle Bot added channel: telegram Channel integration: telegram size: XS labels Jun 4, 2026
@clawsweeper

clawsweeper Bot commented Jun 4, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

Codex review: needs maintainer review before merge. Reviewed June 21, 2026, 7:37 AM ET / 11:37 UTC.

Summary
The PR adds a !suppressSilentReplyFallback guard to Telegram's failure fallback predicate and a regression test for message-tool-only skipped final delivery.

PR surface: Source +1, Tests +34. Total +35 across 2 files.

Reproducibility: yes. at source level. Current main still evaluates the skipped/failed empty-response fallback without suppressSilentReplyFallback, and the linked issue includes live Telegram evidence plus a second user report of the same hotfix.

Review metrics: 2 noteworthy metrics.

  • Fallback Predicate: 1 runtime condition narrowed. The only runtime change decides whether Telegram sends a user-visible generic fallback after a message-tool-only turn.
  • Canonical Candidates: 2 open closing PRs. Two open PRs target the same linked bug, so maintainers should choose one canonical landing path before merge.

Root-cause cluster
Relationship: fixed_by_candidate
Canonical: #90091
Summary: The canonical bug is the open Telegram message-tool-only skipped/failed fallback issue; this PR and the sibling PR are competing candidate fixes for the same missing guard.

Members:

Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything.

Merge readiness
Overall: 🐚 platinum hermit
Proof: 🐚 platinum hermit
Patch quality: 🦞 diamond lobster
Result: ready for maintainer review.

Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch.

Rank-up moves:

Mantis proof suggestion
A native Telegram proof would directly show the message-tool reply without the generic fallback bubble. A maintainer can ask Mantis to capture proof by posting this exact PR comment:

@openclaw-mantis telegram desktop proof: verify a Telegram group message-tool-only reply followed by private final text does not send "No response generated. Please try again."

Risk before merge

  • [P1] Two open PRs target the same canonical bug, so maintainers should land one implementation and close the duplicate only after the chosen fix merges.
  • [P2] Merging intentionally suppresses Telegram's generic empty-response fallback when message-tool-only delivery owns visible output and the automatic lane is skipped or failed without a dispatch error.
  • [P1] This branch has source and unit-test evidence but no live Telegram replay; the Telegram maintainer note prefers real Telegram proof for visible transport behavior when feasible.

Maintainer options:

  1. Choose One Canonical Guard (recommended)
    Pick this PR or fix: suppress Telegram fallback for message-tool-only skips #90095 as the canonical fix, land one, and close the duplicate only after the chosen fix merges.
  2. Request Native Telegram Proof
    If maintainers want visual confirmation beyond source and unit-test proof, ask for Telegram Desktop proof before accepting the visible fallback behavior change.
  3. Accept Message-Tool Ownership
    Maintainers can explicitly accept that message_tool_only ownership suppresses the generic fallback for non-error skipped/failed automatic lanes.

Next step before merge

  • [P2] No automated code repair is needed; maintainers need to choose the canonical open PR and accept the message-delivery invariant before merge.

Security
Cleared: The diff only changes Telegram fallback logic and a colocated test; it does not touch dependencies, workflows, secrets, package metadata, or code execution surfaces.

Review details

Best possible solution:

Land one canonical Telegram guard-and-regression implementation, then close the duplicate PR and the linked issue after the fix merges.

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

Yes, at source level. Current main still evaluates the skipped/failed empty-response fallback without suppressSilentReplyFallback, and the linked issue includes live Telegram evidence plus a second user report of the same hotfix.

Is this the best way to solve the issue?

Yes for the code shape. Applying the existing message-tool-only guard at the Telegram fallback decision is the narrow owner-boundary fix, but maintainers still need to choose the canonical PR.

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning high; reviewed against d1cbe29f3d52.

Label changes

Label justifications:

  • P2: This is a focused Telegram delivery bugfix with visible user impact but limited channel-specific blast radius.
  • merge-risk: 🚨 message-delivery: The diff changes whether Telegram suppresses or sends a visible empty-response fallback after message-tool-only delivery skips automatic final text.
  • rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🐚 platinum hermit and patch quality is 🦞 diamond lobster.
  • 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 member-authored PR; the branch supplies source/unit evidence but no live Telegram replay.
  • mantis: telegram-visible-proof: Mantis should capture Telegram visible proof. The PR changes visible Telegram chat fallback behavior that can be demonstrated in a short Telegram Desktop proof.
Evidence reviewed

PR surface:

Source +1, Tests +34. Total +35 across 2 files.

View PR surface stats
Area Files Added Removed Net
Source 1 1 0 +1
Tests 1 34 0 +34
Docs 0 0 0 0
Config 0 0 0 0
Generated 0 0 0 0
Other 0 0 0 0
Total 2 35 0 +35

What I checked:

Likely related people:

  • vincentkoc: Current blame on the affected predicate and lane tracker points to recent Vincent Koc commits, and history shows recent Telegram dispatcher/test maintenance in this area. (role: current-source and release carrier; confidence: medium; commits: c9758bf2a090, c645ec4555c0, 337fa8c956e9; files: extensions/telegram/src/bot-message-dispatch.ts, extensions/telegram/src/bot-message-dispatch.test.ts, extensions/telegram/src/lane-delivery-state.ts)
  • steipete: Shortlog and file history show broad work on the Telegram dispatcher and extension/channel seams that own this behavior. (role: adjacent plugin/channel refactor contributor; confidence: medium; commits: 54cd8ed25be6, 03a43fe23157, ab96520bbad5; files: extensions/telegram/src/bot-message-dispatch.ts, extensions/telegram/src/bot-message-dispatch.test.ts, extensions/AGENTS.md)
  • obviyus: Recent history shows adjacent Telegram dispatch, abort, compaction, and visible-boundary changes in the same dispatcher and tests. (role: recent Telegram dispatch contributor; confidence: medium; commits: dc3b10285db8, 5aad79571ee6, b85d97f22ccc; files: extensions/telegram/src/bot-message-dispatch.ts, extensions/telegram/src/bot-message-dispatch.test.ts)
  • rubencu: History shows stale-reply delivery fencing and transient preview work near the same reply/fallback surface. (role: adjacent Telegram delivery contributor; confidence: medium; commits: 996eb9a024d0, c65f356ddc95; files: extensions/telegram/src/bot-message-dispatch.ts, extensions/telegram/src/bot-message-dispatch.test.ts)
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.

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.

@clawsweeper clawsweeper Bot added rating: 🐚 platinum hermit Good normal PR readiness with ordinary maintainer review expected. status: 👀 ready for maintainer look ClawSweeper has no concrete contributor-facing blocker left for this PR. mantis: telegram-visible-proof Mantis should capture Telegram visible proof. P2 Normal backlog priority with limited blast radius. merge-risk: 🚨 message-delivery 🚨 May drop, duplicate, misroute, suppress, or wrongly target messages. labels Jun 4, 2026
This was referenced Jun 14, 2026
Open
Open
@clawsweeper clawsweeper Bot added rating: 🦐 gold shrimp Decent PR readiness signal, but merge confidence is limited. rating: 🐚 platinum hermit Good normal PR readiness with ordinary maintainer review expected. and removed rating: 🐚 platinum hermit Good normal PR readiness with ordinary maintainer review expected. rating: 🦐 gold shrimp Decent PR readiness signal, but merge confidence is limited. labels Jun 20, 2026
@openperf
openperf force-pushed the fix/90091-telegram-message-tool-fallback branch from 13f814d to 1e11890 Compare June 21, 2026 11:26
@openperf
openperf force-pushed the fix/90091-telegram-message-tool-fallback branch from 1e11890 to 8cb330d Compare June 21, 2026 11:32
@clawsweeper clawsweeper Bot mentioned this pull request Jul 3, 2026
Merged
@openclaw-barnacle

openclaw-barnacle Bot commented Jul 6, 2026

Copy link
Copy Markdown

This pull request has been automatically marked as stale due to inactivity.
Please add updates or it will be closed.

@openclaw-barnacle openclaw-barnacle Bot added the stale Marked as stale due to inactivity label Jul 6, 2026
@steipete

steipete commented Jul 13, 2026

Copy link
Copy Markdown
Contributor

Thanks for fixing the silent-reply fallback. I’m closing this as a duplicate of #90095: both branches add the same runtime guard, while #90095 is tied directly to the reporter’s reproduction and carries the stronger regression/proof record. The underlying bug is still present on current main, so #90091 should remain open until #90095 is refreshed and landed.

@steipete steipete added duplicate This issue or pull request already exists close:duplicate Closed as duplicate dedupe:child Duplicate issue/PR child in dedupe cluster labels Jul 13, 2026
@steipete steipete closed this Jul 13, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

channel: telegram Channel integration: telegram close:duplicate Closed as duplicate dedupe:child Duplicate issue/PR child in dedupe cluster duplicate This issue or pull request already exists mantis: telegram-visible-proof Mantis should capture Telegram visible proof. merge-risk: 🚨 message-delivery 🚨 May drop, duplicate, misroute, suppress, or wrongly target messages. P2 Normal backlog priority with limited blast radius. rating: 🐚 platinum hermit Good normal PR readiness with ordinary maintainer review expected. size: XS stale Marked as stale due to inactivity status: 👀 ready for maintainer look ClawSweeper has no concrete contributor-facing blocker left for this PR.

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

Telegram message-tool-only turns can still emit empty-response fallback via skipped delivery lane

2 participants

@openperf @steipete