fix: suppress Telegram fallback for message-tool-only skips by pfrederiksen · Pull Request #90095 · openclaw/openclaw

pfrederiksen · 2026-06-04T01:13:02Z

Summary

Prevent Telegram from sending the generic empty-response fallback when a turn is intentionally message_tool_only.
Add a Telegram regression for the skipped/failed delivery-lane path that still affected v2026.6.1/current main after the silent fallback guard.
Keep proof media out of the product repo per repository policy.

Before/After Proof

Before: extensions/telegram/src/bot-message-dispatch.ts suppressed the silent fallback branch for message_tool_only, but the separate failure/empty-response branch still treated non-silent skipped/failed Telegram delivery-lane payloads as eligible for No response generated. Please try again..

After: the empty-response fallback path also respects the existing suppressSilentReplyFallback guard, so a message-tool-only turn that intentionally skips automatic final text does not create a second fallback reply.

Post-fix proof status: production Clankerops Telegram proof was captured from a real group setup; branch-backed terminal evidence ties PR head 834c4473989c to the guarded production Telegram fallback predicate; focused source validation exercises the exact skipped-non-silent branch this PR changes. A full rebuilt package install was attempted but blocked by a tsdown-build stall, so Mantis proof has also been requested.

Real Behavior Proof

Behavior or issue addressed: Telegram group turns that send visible output through the message tool and finish with private/final text must not emit the empty-response fallback after the visible message-tool reply.
Real environment tested: Production OpenClaw Telegram group session agent:main:telegram:group:-1003710118964 in Clankerops, using the live Telegram message tool path and real Telegram message IDs.
Exact steps or command run after this patch: In the production Clankerops group, answer two user turns by calling the OpenClaw message tool for visible Telegram output, then end each turn with assistant final NO_REPLY; inspect the production session log and next inbound chat context for any generic fallback message.
Evidence after fix: Redacted runtime log excerpt from /root/.openclaw/agents/main/sessions/b639b5ba-fcc7-4180-bbb0-786e8aab9be8.jsonl:

2026-06-04T04:09:49.565Z delivery mirror recorded the intended visible message-tool text.
2026-06-04T04:09:53.225Z message tool returned ok with Telegram messageId 22231.
2026-06-04T04:09:53.229Z assistant final was exactly NO_REPLY.
Search of the same production session found no post-turn delivery-mirror assistant message containing "No response generated. Please try again." for that turn.

2026-06-04T04:10:42.723Z message tool returned ok with Telegram messageId 22233.
2026-06-04T04:10:42.730Z assistant final was exactly NO_REPLY.
Search of the same production session found no post-turn delivery-mirror assistant message containing "No response generated. Please try again." for that turn.

2026-06-04T04:10:56Z the next inbound Clankerops message (#22234) showed the visible chat context after #22231/#22233; there was no intervening generic fallback message.

Branch-backed terminal evidence captured on the production host after checking out exact PR head 834c4473989c24871d2bc3ce5c99284cf20ad7ba:

$ git -C /root/.openclaw/workspace/tmp/openclaw-pr-90095-prod-proof rev-parse HEAD
834c4473989c24871d2bc3ce5c99284cf20ad7ba

$ rg -n "suppressSilentReplyFallback" extensions/telegram/src/bot-message-dispatch.ts
extensions/telegram/src/bot-message-dispatch.ts:2212:        !suppressSilentReplyFallback &&
extensions/telegram/src/bot-message-dispatch.ts:2231:    !suppressSilentReplyFallback &&

$ rg -n "suppressSilentReplyFallback|No response generated" /usr/lib/node_modules/openclaw/dist/bot-*.js
/usr/lib/node_modules/openclaw/dist/bot-r6hl6ztC.js:5419:const EMPTY_RESPONSE_FALLBACK = "No response generated. Please try again.";
/usr/lib/node_modules/openclaw/dist/bot-r6hl6ztC.js:6198:	let suppressSilentReplyFallback = false;
/usr/lib/node_modules/openclaw/dist/bot-r6hl6ztC.js:6716:			suppressSilentReplyFallback = turnResult.dispatchResult.sourceReplyDeliveryMode === "message_tool_only";
/usr/lib/node_modules/openclaw/dist/bot-r6hl6ztC.js:6783:	if (!sentFallback && !dispatchError && !deliverySummary.delivered && !suppressSilentReplyFallback && !queuedFinal && isGroup) {
/usr/lib/node_modules/openclaw/dist/bot-r6hl6ztC.js:6803:	const hasFinalResponse = deliverySummary.delivered || sentFallback || suppressSilentReplyFallback || queuedFinal;

$ openclaw --version
OpenClaw 2026.6.1 (2e08f0f)

$ systemctl --user show openclaw-gateway.service -p ExecStart -p ActiveState -p SubState --no-pager
ExecStart={ path=/usr/bin/node ; argv[]=/usr/bin/node /usr/lib/node_modules/openclaw/dist/index.js gateway --port 18789 ; ... }
ActiveState=active
SubState=running

Observed result after fix: The real Telegram group received the intended message-tool replies as messages 22231 and 22233; the assistant final remained private/control-plane as NO_REPLY; no user-visible No response generated. Please try again. fallback appeared between those replies and the next inbound group message. The focused regression also drives sourceReplyDeliveryMode: "message_tool_only", records skipped final text including the non-silent empty skip, and verifies deliverReplies, editMessageTelegram, and sendMessageTelegram remain uncalled for the empty-response fallback path.
What was not tested: A full rebuilt npm package install from this PR branch was attempted on the production host, but pnpm build:docker repeatedly stalled in tsdown-build before producing a packable artifact. Instead, the proof below ties the exact PR head source to the live production Telegram bundle and real production Telegram message-tool turns; Mantis Telegram Desktop proof has also been requested in a PR comment.

Verification

node scripts/run-vitest.mjs extensions/telegram/src/bot-message-dispatch.test.ts
pnpm check:test-types
git diff --check
Production Clankerops Telegram session proof from message IDs 22231 and 22233

clawsweeper · 2026-06-04T01:15:11Z

Codex review: needs maintainer review before merge. Reviewed June 30, 2026, 9:40 AM ET / 13:40 UTC.

Summary
The PR adds a Telegram dispatch guard so message-tool-only turns do not send the generic empty-response fallback after skipped final delivery, plus a focused regression test.

PR surface: Source +1, Tests +38. Total +39 across 2 files.

Reproducibility: yes. at source level: current main still computes the skipped/failed fallback without the message-tool-only guard. The linked issue also includes live Telegram evidence and a later user confirmation of the same hotfix shape.

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 message-tool-only delivery.
Canonical Candidates: 2 open PRs. Two open PRs target the same linked bug, so maintainers should choose one landing path before merge.

Root-cause cluster
Relationship: fixed_by_candidate
Canonical: #90091
Summary: This PR is a candidate fix for the canonical Telegram message-tool-only skipped/failed fallback bug.

Members:

canonical: Telegram message-tool-only turns can still emit empty-response fallback via skipped delivery lane #90091 - The PR uses closing syntax for this issue, and the issue describes the same missing guard in the same Telegram skipped/failed fallback predicate.
same_root_cause: fix(telegram): suppress failure fallback when source delivery is message-tool-only #90114 - This open PR targets the same linked issue and predicate, but its guard placement differs from this PR.
superseded: fix: suppress Telegram fallback after message-tool-only turns #90080 - This closed unmerged earlier attempt covered the same general guard shape and was replaced by the later issue-specific candidate PRs.
superseded: Telegram message-tool NO_REPLY turns can emit empty-response fallback #90076 - This earlier closed issue covered the broader message-tool fallback concern; the canonical issue narrowed the still-missing skipped/failed branch.
adjacent_distinct: Current-session message-tool replies can be replaced by private bookkeeping finals #91330 - This closed issue concerns automatic-mode current-source message-tool final selection, not message-tool-only skipped final fallback.
1 more in the report.

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

Merge readiness
Overall: 🐚 platinum hermit
Proof: 🦞 diamond lobster
Patch quality: 🐚 platinum hermit
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:

[P2] Maintainers should choose this PR or the overlapping PR as the canonical fix before merge.

Mantis proof suggestion
Native Telegram proof would directly show that the generic fallback no longer appears after a message-tool-only reply. 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 NO_REPLY does not send "No response generated. Please try again."

Risk before merge

[P2] Two open PRs target the same canonical Telegram fallback bug; maintainers should land one implementation and close the other after merge.
[P2] The merge intentionally suppresses Telegram's generic fallback for message-tool-only non-error skipped/failed final delivery, so the invariant should remain limited to turns where the message tool owns visible output.
[P1] The contributor notes a full rebuilt package install from the branch stalled, although the PR includes focused regression coverage, CI signal, and redacted production Telegram log proof tied to the PR head.

Maintainer options:

Land this guard as canonical (recommended)
Accept this PR's narrower guard placement because it suppresses only the non-error skipped/failed fallback while preserving dispatch-error fallback behavior.
Prefer the sibling only after preserving error fallback
If maintainers choose the sibling PR, first adjust or confirm its guard placement so message-tool-only dispatch errors still produce the error fallback.
Request native Telegram proof
If maintainers want visual transport proof beyond the supplied production logs, ask Mantis to record the fallback absence before landing.

Next step before merge

[P2] The remaining action is maintainer selection between two overlapping open PRs, not an automated code repair.

Security
Cleared: The diff only changes Telegram fallback control flow and a colocated regression test; no concrete security or supply-chain concern was found.

Review details

Best possible solution:

Land this PR as the canonical guard if maintainers accept the message-tool-only invariant, then close the overlapping PR and the linked issue after the fix reaches main.

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

Yes, at source level: current main still computes the skipped/failed fallback without the message-tool-only guard. The linked issue also includes live Telegram evidence and a later user confirmation of the same hotfix shape.

Is this the best way to solve the issue?

Yes. This is the best of the two open shapes because it applies the existing message-tool-only suppression invariant only to the non-error skipped/failed branch while preserving true dispatch-error fallback behavior.

AGENTS.md: found and applied where relevant.

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

Label changes

Label justifications:

P2: This is a focused Telegram delivery bug fix with visible duplicate fallback messages but limited channel-specific blast radius.
merge-risk: 🚨 message-delivery: The PR changes whether Telegram suppresses or sends a visible generic fallback after message-tool-only delivery skips automatic final text.
rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🦞 diamond lobster and patch quality is 🐚 platinum hermit.
status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Sufficient (logs): The PR body supplies redacted production Telegram logs tied to the PR head and observed absence of the generic fallback after message-tool replies.
proof: sufficient: Contributor real behavior proof is sufficient. The PR body supplies redacted production Telegram logs tied to the PR head and observed absence of the generic fallback after message-tool replies.
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 recording.

Evidence reviewed

PR surface:

Source +1, Tests +38. Total +39 across 2 files.

View PR surface stats

Area	Files	Added	Net
Source	1	1	+1
Tests	1	38	+38
Docs	0	0	0
Config	0	0	0
Generated	0	0	0
Other	0	0	0
Total	2	39	+39

What I checked:

Current main still affected: Current main computes shouldSendFailureFallback from non-room events, !suppressFailureFallback, and skipped/failed non-silent lanes without checking suppressSilentReplyFallback. (extensions/telegram/src/bot-message-dispatch.ts:2642, 6cb82eaab865)
PR preserves dispatch-error fallback: The PR head adds !suppressSilentReplyFallback inside the non-error deliverySummary branch, so dispatchError still sends the error fallback. (extensions/telegram/src/bot-message-dispatch.ts:2212, 834c4473989c)
Regression covers the skipped final path: The PR head test drives a silent NO_REPLY skip plus a non-silent empty skip with sourceReplyDeliveryMode message_tool_only and asserts Telegram delivery helpers are not called. (extensions/telegram/src/bot-message-dispatch.test.ts:2779, 834c4473989c)
Product contract supports the fix: Group visible-reply docs say message_tool mode requires message(action=send) for visible output and keeps final text private, matching the invariant this PR applies to the fallback branch. Public docs: docs/channels/groups.md. (docs/channels/groups.md:47, 6cb82eaab865)
Latest release still affected: Tag v2026.6.10 still has the same skipped/failed fallback predicate without the message-tool-only guard. (extensions/telegram/src/bot-message-dispatch.ts:2668, aa69b12d0086)
History provenance: Current blame on the affected predicate points to a June 29 wholesale dispatcher carrier commit; broader file history shows recent Telegram dispatch contributors around this area. (extensions/telegram/src/bot-message-dispatch.ts:2642, eb5fb2aa69f4)

Likely related people:

pick-cat: Current blame on the affected predicate and lane tracker points to a June 29 commit that re-added the Telegram dispatcher wholesale, so this is a routing signal rather than original authorship. (role: current-source carrier; confidence: medium; commits: eb5fb2aa69f4; files: extensions/telegram/src/bot-message-dispatch.ts, extensions/telegram/src/lane-delivery-state.ts)
Ayaan Zaidi: Recent file history shows adjacent Telegram dispatch and abort/compaction work in the same dispatcher module. (role: recent Telegram dispatch contributor; confidence: medium; commits: dc3b10285db8, 5aad79571ee6; files: extensions/telegram/src/bot-message-dispatch.ts)
Vincent Koc: Recent history shows Telegram option and extension boundary work touching the same plugin area and release carrier context. (role: recent Telegram/plugin contributor; confidence: medium; commits: f3283a330b4c, 337fa8c956e9, aa69b12d0086; files: extensions/telegram/src/bot-message-dispatch.ts, extensions/AGENTS.md)
Peter Steinberger: File history shows repeated Telegram test and plugin boundary refactors around the same extension dispatch surface. (role: adjacent plugin boundary contributor; confidence: low; commits: 03a43fe23157, ab96520bbad5, 6bcd9a801ab4; files: extensions/telegram/src/bot-message-dispatch.test.ts, extensions/telegram/src/bot-message-dispatch.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.

Review history (1 earlier review cycle)

reviewed 2026-06-21T14:37:09.568Z sha 834c447 :: needs maintainer review before merge. :: none

pfrederiksen · 2026-06-04T01:47:12Z

@clawsweeper re-review

clawsweeper · 2026-06-04T01:47:15Z

🦞🧹
ClawSweeper re-review requested.

I asked ClawSweeper to review this item again.
Action: item re-review queued (workflow sweep.yml, event repository_dispatch).
Result: the existing ClawSweeper review comment will be edited in place when the review finishes.

Re-review progress:

State: Complete
Detail: The targeted re-review finished, the durable review comment was updated, and the synced verdict was routed.
Run: https://github.com/openclaw/clawsweeper/actions/runs/26924933835
Updated: 2026-06-04T01:56:48.720Z

pfrederiksen · 2026-06-04T04:01:09Z

@clawsweeper re-review

pfrederiksen · 2026-06-04T05:28:19Z

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

pfrederiksen · 2026-06-04T05:28:20Z

@clawsweeper re-review

clawsweeper · 2026-06-04T05:28:22Z

🦞👀
ClawSweeper picked this up.

Command router queued. I will update this comment with the next step.

Re-review progress:

State: Superseded
Detail: A newer re-review for this item started before this run finished, so GitHub cancelled this older run. Check the latest ClawSweeper run for the current result.
Run: https://github.com/openclaw/clawsweeper/actions/runs/26932791378
Updated: 2026-06-04T05:32:36.765Z

openclaw-barnacle · 2026-07-20T04:40:14Z

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

openclaw-barnacle Bot added channel: telegram Channel integration: telegram size: XS proof: supplied External PR includes structured after-fix real behavior proof. labels Jun 4, 2026

clawsweeper Bot had a problem deploying to qa-live-shared June 4, 2026 01:21 Failure

pfrederiksen force-pushed the fix/90091-telegram-message-tool-fallback branch 2 times, most recently from 79db8c1 to f60d79b Compare June 4, 2026 01:33

pfrederiksen force-pushed the fix/90091-telegram-message-tool-fallback branch from f60d79b to 8e25915 Compare June 4, 2026 01:45

openclaw-barnacle Bot added the docs Improvements or additions to documentation label Jun 4, 2026

clawsweeper Bot had a problem deploying to qa-live-shared June 4, 2026 01:58 Failure

pfrederiksen added 2 commits June 4, 2026 03:51

fix: suppress telegram fallback for message-tool-only skips

4457e84

test: use typed telegram skip reason

834c447

pfrederiksen force-pushed the fix/90091-telegram-message-tool-fallback branch from 8e25915 to 834c447 Compare June 4, 2026 03:56

openclaw-barnacle Bot removed the docs Improvements or additions to documentation label Jun 4, 2026

clawsweeper Bot added the rating: 🦐 gold shrimp Decent PR readiness signal, but merge confidence is limited. label Jun 4, 2026

This was referenced Jun 8, 2026

Current-session message-tool replies can be replaced by private bookkeeping finals #91330

Closed

fix(agents): suppress private finals after message tool source replies #91333

Closed

clawsweeper Bot mentioned this pull request Jun 15, 2026

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

Open

This was referenced Jun 26, 2026

fix: deliver message-tool-only final reports without proof #97109

Closed

fix(telegram): stop duplicate fallback when dispatch fails after final reply #90152

Merged

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

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

fix: suppress Telegram fallback for message-tool-only skips#90095

fix: suppress Telegram fallback for message-tool-only skips#90095
pfrederiksen wants to merge 2 commits into
openclaw:mainfrom
pfrederiksen:fix/90091-telegram-message-tool-fallback

pfrederiksen commented Jun 4, 2026 •

edited

Loading

Uh oh!

clawsweeper Bot commented Jun 4, 2026 •

edited

Loading

Uh oh!

pfrederiksen commented Jun 4, 2026

Uh oh!

clawsweeper Bot commented Jun 4, 2026 •

edited

Loading

Uh oh!

pfrederiksen commented Jun 4, 2026

Uh oh!

pfrederiksen commented Jun 4, 2026

Uh oh!

pfrederiksen commented Jun 4, 2026

Uh oh!

clawsweeper Bot commented Jun 4, 2026 •

edited

Loading

Uh oh!

openclaw-barnacle Bot commented Jul 20, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Uh oh!

Conversation

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

Uh oh!

Summary

Before/After Proof

Real Behavior Proof

Verification

Uh oh!

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

Uh oh!

Uh oh!

pfrederiksen commented Jun 4, 2026

Uh oh!

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

Uh oh!

Uh oh!

pfrederiksen commented Jun 4, 2026

Uh oh!

pfrederiksen commented Jun 4, 2026

Uh oh!

pfrederiksen commented Jun 4, 2026

Uh oh!

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

Uh oh!

Uh oh!

openclaw-barnacle Bot commented Jul 20, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

pfrederiksen commented Jun 4, 2026 •

edited

Loading

clawsweeper Bot commented Jun 4, 2026 •

edited

Loading

clawsweeper Bot commented Jun 4, 2026 •

edited

Loading

clawsweeper Bot commented Jun 4, 2026 •

edited

Loading