OpenClaw Telegram Silent Replies Remain Open While Exact-Send Recovery Gets a Separate Fix

OpenClaw operators should not treat every recent delivery repair as closure of the recurring Telegram silent-reply problem. Issue #121058 remains open with repeated reports of a visible channel turn dispatching without any queued reply payload. A separate merged fix, PR #121587, repairs exact sends that reached the provider but failed durable settlement.

The distinction matters: one failure produces no real reply payload; the other can produce a real platform message whose local custody remains ambiguous. Their mitigation and retry safety are opposite.

The open Telegram signature

The issue reports recurring Telegram group turns using deepseek-v4-flash with this diagnostic:

visible channel turn dispatched with no queued reply payloads: channel=telegram

The user sees a generic “No reply was generated for this message” fallback. According to the reporter, occurrences continued after the earlier issue and repair intended to recover directed turns after empty model replies.

The evidence is a public bug report with repeated monitoring observations, not a maintainer-confirmed root cause. It has no linked development branch or landed fix at verification time. Operators should therefore treat it as an active incident signature, not claim that DeepSeek or Telegram is conclusively at fault.

Do not blindly retry a no-payload turn

A missing queued reply does not prove that every tool or external side effect inside the agent turn was absent. The safe response is:

1. capture the exact session, inbound message and run identity;
2. inspect model outcome, tool activity, outbound queue and channel receipt separately;
3. tell the user the answer failed only when no visible reply exists;
4. retry the response generation only after reconciling side effects; and
5. use an idempotency key or a harmless recovery prompt where possible.

Switching models may be a practical mitigation if the signature is isolated to one route, but it is not a verified fix. Preserve one redacted failing example for upstream diagnosis.

Exact sends had the inverse ambiguity

PR #121587 fixes a different path. An exact-reconciliation send could reach the provider successfully while dispatch began under a producer claim. Dispatch cleared that claim without publishing the platform-send attempt identity, so the later acknowledgement failed its ownership check with “Delivery platform claim was lost.”

The unresolved row could then be recovered or replayed after restart even though the platform had already sent the message. Later recovery could also show a spurious “couldn’t confirm my previous reply” notice.

The merged repair atomically promotes the live producer claim into send_attempt_started and publishes the attempt identity. Existing attempt owners remain fenced, stale ownership is rejected, and stronger unknown_after_send evidence is preserved.

Interpretation: exact-send recovery must prefer duplicate avoidance after provider success. By contrast, a genuine no-payload turn may need a new answer. Treating both as “retry delivery” can either duplicate a real message or fail to repair a missing one.

Monitoring and acceptance

Create separate alerts for:

• visible turns with zero queued reply payloads;
• provider success followed by settlement failure;
• durable unknown_after_send outcomes;
• recovery notices shown to users; and
• the same inbound message or durable delivery item producing more than one platform message ID.

For the exact-send repair, use a fake provider that returns a deterministic message ID, force dispatch from a producer-claimed row, then restart recovery. Require one provider call, one platform message, a settled row and no ambiguity notice.

For the open Telegram issue, use a disposable group and inert prompt. Capture the complete model/tool/outbound timeline but do not automate repeated user-facing retries until side-effect reconciliation is proven.

Evidence and limits

The exact-send PR reports a Matrix provider-success trace, regression-first required and best-effort cases, recovery tests and focused suites. The Telegram evidence is user-reported and remains unresolved; OpenClaw Academy verified that the issue is open and that its described signature is distinct from the merged exact-send settlement repair. We did not reproduce either against a live recipient.

Relevant collector records are 52740, 53127, 53218 and 53247.

Bottom line

Keep alerting on visible channel turn dispatched with no queued reply payloads; there is no verified landed closure in the supplied evidence. Upgrade and test the exact-send settlement fix separately, then make your recovery automation distinguish “no reply existed” from “the provider sent it but local settlement is ambiguous.”