Skip to content

Guard Telegram runtime progress and report delivery#80021

Closed
baragozhelper-ux wants to merge 3 commits into
openclaw:mainfrom
baragozhelper-ux:openclaw-runtime-comms-guard-durable-upstream-fix-01
Closed

Guard Telegram runtime progress and report delivery#80021
baragozhelper-ux wants to merge 3 commits into
openclaw:mainfrom
baragozhelper-ux:openclaw-runtime-comms-guard-durable-upstream-fix-01

Conversation

@baragozhelper-ux

@baragozhelper-ux baragozhelper-ux commented May 9, 2026

Copy link
Copy Markdown

Summary

Updates the durable Telegram runtime communications guard so visible service/process leaks are blocked both at the direct Telegram send helper and at the automatic Telegram reply delivery path.

Changes

  • Enforces the guard in sendMessageTelegram, the direct Telegram API delivery helper.
  • Enforces the guard in deliverReplies, the automatic assistant reply path used for normal Telegram replies.
  • Keeps progress/report dedupe in the shared guard ledger outside task_store.
  • Suppresses visible technical leak markers before delivery, including:
    • MODEL-GATE
    • model-gate fields such as task_type: / risk_level: / proceed_status:
    • Gateway restart ...
    • Reason: / Run: restart hints
    • openclaw doctor
    • Working...
    • command/exec/tool-output style text
    • raw JSON, stack traces, SHA/byte-count diagnostics
  • Allows requested file/media delivery to continue even if adjacent technical text is suppressed, so a .md artifact can be delivered without leaking MODEL-GATE as caption text.
  • Keeps static Russian progress (Идет работа.) deduped and allowed once.
  • Dedupes local/report/artifact media at the Telegram delivery boundary.
  • Removes duplicate guard enforcement from the outbound adapter so delivery boundaries are authoritative.

Verification

  • npm test -- --run extensions/telegram/src/bot/delivery.test.ts extensions/telegram/src/send.test.ts extensions/telegram/src/outbound-adapter.test.ts
  • npm run lint:extensions -- extensions/telegram/src/runtime-comms-guard.ts extensions/telegram/src/send.ts extensions/telegram/src/send.test.ts extensions/telegram/src/send.test-harness.ts extensions/telegram/src/bot/delivery.replies.ts extensions/telegram/src/bot/delivery.test.ts extensions/telegram/src/outbound-adapter.ts extensions/telegram/src/outbound-adapter.test.ts
  • Local installed runtime syntax checks for patched Telegram guard/send/delivery files.
  • Gateway restart after installed-runtime patch.

Regression coverage

Adds tests for the real adaptation scenario:

  • automatic Telegram replies suppress MODEL-GATE;
  • a requested .md file is delivered immediately;
  • MODEL-GATE is not sent as text or media caption;
  • a short user-facing summary remains sendable.

Notes

This remains a draft PR for review. It does not change upstream main unless it is accepted and merged.

@openclaw-barnacle openclaw-barnacle Bot added channel: telegram Channel integration: telegram size: M triage: needs-real-behavior-proof Candidate: external PR needs after-fix proof from a real setup. labels May 9, 2026
@clawsweeper

clawsweeper Bot commented May 9, 2026

Copy link
Copy Markdown
Contributor

Codex review: needs real behavior proof before merge.

Summary
Adds a Telegram runtime communications guard in sendMessageTelegram and automatic reply delivery, with persistent dedupe and regression tests for technical text suppression and media delivery.

Reproducibility: yes. Source inspection is enough to reproduce the introduced failure modes: the PR calls guard checks before delivery can fail, while current main shows checkAndRecord writes immediately and current tests/docs define the progress rendering contract being bypassed.

Real behavior proof
Needs real behavior proof before merge: The PR body lists checks and a gateway restart but includes no inspectable after-fix Telegram screenshot, terminal output, logs, recording, or linked artifact; contributors should redact private data and update the PR body to trigger re-review.

Next step before merge
External draft PR has blocking correctness findings and missing real behavior proof; the next action is contributor revision/proof before maintainer review.

Security
Cleared: No concrete security or supply-chain regression was found in the reviewed diff.

Review findings

  • [P1] Record dedupe only after successful delivery — extensions/telegram/src/send.ts:619-627
  • [P2] Preserve configured progress rendering — extensions/telegram/src/bot-message-dispatch.ts:555
  • [P2] Scope media dedupe to report artifacts — extensions/telegram/src/runtime-comms-guard.ts:168-170
Review details

Best possible solution:

Keep the guard Telegram-owned at the final delivery boundary, but commit dedupe only after successful sends, preserve the existing progress renderer/configuration, and scope media dedupe to real report artifacts with focused tests plus redacted live proof.

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

Yes. Source inspection is enough to reproduce the introduced failure modes: the PR calls guard checks before delivery can fail, while current main shows checkAndRecord writes immediately and current tests/docs define the progress rendering contract being bypassed.

Is this the best way to solve the issue?

No. Moving suppression to Telegram delivery boundaries is reasonable, but this implementation is not the best fix because it records dedupe before successful delivery, hard-codes progress text, and over-dedupes local media.

Full review comments:

  • [P1] Record dedupe only after successful delivery — extensions/telegram/src/send.ts:619-627
    These guard checks run before media loading or Telegram API sends. Because createPersistentDedupe.checkAndRecord persists immediately, a failed media load or transient Telegram send error will still mark the progress/report as delivered and suppress retries for the guard TTL. Use a claim/commit/release flow or record only after the send succeeds.
    Confidence: 0.93
  • [P2] Preserve configured progress rendering — extensions/telegram/src/bot-message-dispatch.ts:555
    Hard-coding Идет работа. bypasses the existing progress renderer, including streaming.progress.label, max-line handling, and tool progress details. Current Telegram tests and docs expect configured labels and tool text in progress drafts, so this regresses released behavior unless the contract is intentionally changed.
    Confidence: 0.9
  • [P2] Scope media dedupe to report artifacts — extensions/telegram/src/runtime-comms-guard.ts:168-170
    This treats every local media URL as a report artifact. Telegram delivery supports local images, audio, video, voice, and documents, so sending the same local photo or voice note again in the same route would be suppressed for seven days even though the PR only intends report/artifact dedupe.
    Confidence: 0.86

Overall correctness: patch is incorrect
Overall confidence: 0.9

What I checked:

  • PR diff records guard state before delivery can succeed: The provided PR patch at head 611909fb6a2702033781596c25a0781bd54c026a adds shouldSendTelegramRuntimeCommsMedia and shouldSendTelegramRuntimeCommsText at the start of sendMessageTelegram, before media loading and the Telegram API send path, so a guard using immediate persistent recording can commit dedupe before delivery is proven. (extensions/telegram/src/send.ts:619, 611909fb6a27)
  • Persistent dedupe writes during checkAndRecord: Current main writes data[key] = now inside checkAndRecord before returning success, confirming that pre-send guard checks persist the dedupe marker immediately. (src/plugin-sdk/persistent-dedupe.ts:209, fa0506bd3185)
  • Telegram progress rendering is a released configurable contract: Current tests expect progress mode to render configured labels such as Shelling and tool details such as Exec, and the Telegram/streaming docs describe streaming.progress and command-text policy for Telegram progress drafts. (extensions/telegram/src/bot-message-dispatch.test.ts:1123, fa0506bd3185)
  • Telegram docs define progress and command-text configuration: The Telegram docs state that progress keeps an editable status draft, that tool progress is enabled by default to preserve released behavior, and that command text policy belongs under streaming.progress. Public docs: docs/channels/telegram.md. (docs/channels/telegram.md:280, fa0506bd3185)
  • Current Telegram sends support arbitrary local media: Current main loads mediaUrl before choosing photo/video/audio/voice/document senders, and the outbound adapter test forwards a local /tmp/image.png; this supports the finding that treating every local URL as a report artifact is over-broad. (extensions/telegram/src/send.ts:800, fa0506bd3185)
  • Prior ClawSweeper comment already requested fixes and proof: The existing PR discussion includes a ClawSweeper review with the same three correctness findings and marks the PR as needing real behavior proof before merge.

Likely related people:

  • @steipete: Blame on the current Telegram progress renderer, Telegram send path, and persistent dedupe helper points to Peter Steinberger, and local history shows many recent Telegram/plugin-SDK maintenance commits in this area. (role: recent maintainer and adjacent owner; confidence: high; commits: e3b2ddb7578a, 2fd1a5274ad2, 5802d112da3a; files: extensions/telegram/src/bot-message-dispatch.ts, extensions/telegram/src/send.ts, src/plugin-sdk/persistent-dedupe.ts)
  • Robin Waslander: Local Telegram history includes multiple recent merged fixes around Telegram reply/send behavior, including empty text replies, message splitting, and reply-to validation. (role: recent Telegram delivery contributor; confidence: medium; commits: 4d6c8edd7484, ab2ef7bbfc5c, 865160e57292; files: extensions/telegram/src)

Remaining risk / open question:

  • The PR body lists tests and a restart but provides no inspectable real Telegram after-fix proof.
  • The branch is still a draft and has existing blocking correctness findings.

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

@baragozhelper-ux

Copy link
Copy Markdown
Author

Closing this draft as superseded by merged #80075. The #80021 branch addressed the visible Telegram delivery-boundary symptom, but #80075 fixes the higher-level embedded payload selection root cause so accumulated assistantTexts no longer become multiple channel-visible final replies. I will not continue the downstream guard branch. If any residual Telegram leak reproduces on current main after #80075, I will open a new narrow residual PR from main with focused reproduction and proof.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

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

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant