Skip to content

fix(telegram): suppress NO_REPLY sentinel before sendMessageTelegram API call#68304

Open
1aifanatic wants to merge 2 commits intoopenclaw:mainfrom
1aifanatic:fix/telegram-silent-reply-guard
Open

fix(telegram): suppress NO_REPLY sentinel before sendMessageTelegram API call#68304
1aifanatic wants to merge 2 commits intoopenclaw:mainfrom
1aifanatic:fix/telegram-silent-reply-guard

Conversation

@1aifanatic
Copy link
Copy Markdown

@1aifanatic 1aifanatic commented Apr 17, 2026

Summary

  • sendMessageSlack guards against NO_REPLY sentinel tokens before calling the Slack API
  • sendMessageTelegram was missing the same guard — a NO_REPLY token could reach the Telegram API
  • This caused a visible flash of text (truncated to "NO") that Telegram briefly showed and then deleted once the stream handler suppressed the sentinel

Change Type

  • Bug fix

Scope

  • Integrations

Linked Issue/PR

Root Cause

When an agent outputs visible narration text before the NO_REPLY sentinel in the same response, the text streams to Telegram as a live preview. OpenClaw's stream handler correctly suppresses NO_REPLY at the end, but the preview was already delivered. sendMessageSlack has a defensive guard that intercepts NO_REPLY tokens before any API call; sendMessageTelegram lacked this guard.

Fix

Added isSilentReplyText check at the entry of sendMessageTelegram, matching the existing Slack pattern. Returns a suppressed no-op result without making a network call when the text is a NO_REPLY sentinel and no media is attached.

@1aifanatic
fix(telegram): suppress NO_REPLY sentinel before sendMessageTelegram …
bc77d95 
…API call

sendMessageSlack already guards against silent reply tokens before calling
the API. sendMessageTelegram was missing the same guard, so a NO_REPLY
sentinel could reach the Telegram API and cause a visible flash of text
(truncated to "NO") that gets deleted once the stream handler suppresses it.

Add an isSilentReplyText check at the top of sendMessageTelegram — matching
the existing Slack pattern — so NO_REPLY tokens are intercepted before any
network call is made.

Closes openclaw#38603
@openclaw-barnacle openclaw-barnacle Bot added channel: telegram Channel integration: telegram size: XS labels Apr 17, 2026
@greptile-apps
Copy link
Copy Markdown
Contributor

greptile-apps Bot commented Apr 17, 2026

Greptile Summary

Adds the missing isSilentReplyText guard to sendMessageTelegram, mirroring the existing Slack pattern, so that a bare NO_REPLY sentinel is suppressed before any Telegram API call is made rather than briefly appearing as a live preview that the stream handler later has to delete. The guard condition (!opts.mediaUrl) correctly omits a blocks check because TelegramSendOpts carries no blocks-equivalent structured-content field.

Confidence Score: 5/5

Safe to merge — minimal, targeted fix with no behaviour change for normal messages.

Single focused guard matching the proven Slack pattern; return type satisfies TelegramSendResult; no other opts bypass suppression; no tests broken.

No files require special attention.

Reviews (1): Last reviewed commit: "fix(telegram): suppress NO_REPLY sentine..." | Re-trigger Greptile

@clawsweeper clawsweeper Bot mentioned this pull request Apr 26, 2026
Open
@clawsweeper
Copy link
Copy Markdown
Contributor

clawsweeper Bot commented Apr 30, 2026 •
edited
Loading

Codex review: needs real behavior proof before merge.

Summary
Adds a Telegram send-level silent-reply guard, regression tests for bare and inline-keyboard NO_REPLY sends, and an Unreleased changelog entry.

Reproducibility: yes. Source inspection on current main shows a direct sendMessageTelegram(..., "NO_REPLY", ...) has no exact silent-token early return before the Telegram api.sendMessage path, while Slack has that guard.

Real behavior proof
Needs real behavior proof before merge: Missing: the PR has no after-fix live Telegram, terminal/log, screenshot, recording, or linked artifact proof; the contributor should attach redacted real-output evidence and update the PR body to trigger review, or ask a maintainer to comment @clawsweeper re-review.

Next step before merge
Human/contributor follow-up is needed because real behavior proof must come from an actual setup and the branch is merge-conflicted; ClawSweeper should not open a separate repair while this closing PR is active.

Security
Cleared: Cleared: the diff only changes Telegram send control flow, focused tests, and changelog text, with no dependency, workflow, secret, package-resolution, or artifact-execution changes.

Review details

Best possible solution:

Land the narrow Telegram-owned guard with regression coverage and changelog after a clean rebase and redacted real behavior proof from a Telegram setup.

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

Yes. Source inspection on current main shows a direct sendMessageTelegram(..., "NO_REPLY", ...) has no exact silent-token early return before the Telegram api.sendMessage path, while Slack has that guard.

Is this the best way to solve the issue?

Yes for the narrow adapter-defense gap. The latest patch preserves media and inline-button payloads like the Slack guard, but it still needs a current-main rebase and real behavior proof before merge.

What I checked:

  • Current main lacks Telegram guard: On current main, sendMessageTelegram resolves the Telegram API context and proceeds into normal text delivery with no isSilentReplyText early return. (extensions/telegram/src/send.ts:585, 95a1c915312a)
  • Current main sends exact text through Telegram API: The no-media path only rejects empty text, then calls sendChunkedText; the text chunk sender reaches api.sendMessage, so exact NO_REPLY is source-reproducible as an API send today. (extensions/telegram/src/send.ts:962, 95a1c915312a)
  • Slack parity guard exists: Slack already normalizes message text and suppresses exact silent replies only when no media or blocks are attached, and its tests cover suppression plus block preservation. (extensions/slack/src/send.ts:540, 95a1c915312a)
  • PR head preserves Telegram payloads: The latest PR head suppresses only when isSilentReplyText(trimmedText) is true and neither media nor buttons are attached, addressing the prior inline-keyboard finding. (extensions/telegram/src/send.ts:620, e2c30d921148)
  • PR head adds focused tests: The branch adds one test proving bare NO_REPLY avoids sendMessage and one proving NO_REPLY with inline buttons still sends reply_markup. (extensions/telegram/src/send.test.ts:1768, e2c30d921148)
  • PR metadata blocks merge: GitHub reports the PR as open, unmerged, mergeable_state: dirty, mergeable: false, and 10080 commits behind current main; labels include triage: needs-real-behavior-proof. (e2c30d921148)

Likely related people:

  • steipete: Recent GitHub commit history shows repeated maintenance of Telegram sender behavior, Telegram sender tests, and auto-reply helper exports around the affected send and silent-token surfaces. (role: recent maintainer; confidence: medium; commits: 2f828dbde964, 332df49d2c11, 82e8518bd7b5; files: extensions/telegram/src/send.ts, extensions/telegram/src/send.test.ts, src/auto-reply/tokens.ts)
  • vincentkoc: Recent history and PR assignment point to Telegram delivery, interactive fallback, test seam, and current sender-contract work adjacent to this guard. (role: adjacent owner; confidence: medium; commits: b0b5983ce393, 09cb77ed38e9, 79d7fdce932b; files: extensions/telegram/src/bot/delivery.replies.ts, extensions/telegram/src/send.ts, extensions/telegram/src/send.test.ts)
  • obviyus: Related history and review timeline connect this maintainer to Telegram reply/preview and NO_REPLY suppression behavior that overlaps the reported flash path. (role: prior silent-preview maintainer; confidence: medium; commits: 16c608e3937e, 3d998828b930, 5aad79571ee6; files: extensions/telegram/src/bot/delivery.replies.ts, src/auto-reply/tokens.ts, src/gateway/server-chat.agent-events.test.ts)

Remaining risk / open question:

  • The branch is currently dirty against current main; rebase may need to adapt the new tests to the current required cfg contract in sendMessageTelegram.
  • No after-fix live Telegram, terminal/log, screenshot, recording, or linked artifact proof is attached; mocked tests do not prove the user-visible Telegram behavior.
  • The send-level guard fixes exact adapter sends, but any remaining pre-sentinel streaming flash would need separate buffering work if it still reproduces after this lands.

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

Re-review progress:

@vincentkoc vincentkoc self-assigned this May 3, 2026
@openclaw-barnacle openclaw-barnacle Bot added the triage: needs-real-behavior-proof Candidate: external PR needs after-fix proof from a real setup. label May 7, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

@vincentkoc vincentkoc

Labels

channel: telegram Channel integration: telegram size: XS triage: needs-real-behavior-proof Candidate: external PR needs after-fix proof from a real setup.

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

Telegram: sendMessageTelegram missing isSilentReply guard (causes flash of streamed text before NO_REPLY suppression)

2 participants

@1aifanatic @vincentkoc