Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix [Bug]: Telegram outbound send never occurs in supergroup topics on 2026.5.4 - "Skipping message_end safety send for text_end channel" [1 pull requests, 2 comments, 3 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#77833•Fetched 2026-05-06 06:20:35
View on GitHub
Comments
2
Participants
3
Timeline
9
Reactions
2
Author
jcolmedojcolmedo
Participants
clawsweeper[bot]clawsweeper[bot]jcolmedojcolmedoneeravmakwananeeravmakwana
Timeline (top)
referenced ×4commented ×2closed ×1cross-referenced ×1

In 2026.5.4, Telegram outbound send never occurs in supergroup forum topics; every run completes with outcome=completed but no sendMessage ok appears in logs and reply never reaches Telegram.

Root Cause

In 2026.5.4, Telegram outbound send never occurs in supergroup forum topics; every run completes with outcome=completed but no sendMessage ok appears in logs and reply never reaches Telegram.

Fix Action

Fixed

PR fix notes

PR #77840: fix(embed): arm lastBlockReplyText only after block reply emission

Description (problem / solution / changelog)

Summary

emitBlockChunk set lastBlockReplyText before replyDirectiveAccumulator.consume() confirmed a renderable outbound payload and before emitBlockReply ran. When consume() returned null (for example silent NO_REPLY-only streamed text) or the cleaned payload was empty, handleMessageEnd still saw lastBlockReplyText !== null, logged Skipping message_end safety send for text_end channel, and skipped the fallback path—so channels such as Telegram never received a reply even though the transcript showed a completed assistant message.

This change records lastBlockReplyText only immediately before an actual block reply emission (after the same empty-payload guard as before).

Root cause

Stale lastBlockReplyText was treated as proof of delivery for text_end break mode when no onBlockReply payload had been produced.

Linked issue

Fixes #77833.

Why this is safe

  • No change to allowlists, mention rules, routing, or outbound transport; only when the embed layer marks a block chunk as having been delivered vs when it only attempted streaming ingestion.
  • Existing duplicate-suppression stays based on emitted chunks; silently skipped/non-renderable directive chunks no longer falsely arm the message_end suppressor.

Security / runtime controls

Unchanged: channel admission, auth, session policy, tooling allowlists, Telegram API parameters, and message-content policy enforcement beyond this delivery bookkeeping marker.

Real behavior proof

  • Not exercised in Docker against a live Telegram supergroup forum in this iteration.
  • Automated: regression test message_end block-replies visible text when text_end streamed only silent NO_REPLY chunks in src/agents/pi-embedded-subscribe.subscribe-embedded-pi-session.emits-block-replies-text-end-does-not.test.ts.
  • Validation: pnpm exec vitest run src/agents/pi-embedded-subscribe.subscribe-embedded-pi-session.emits-block-replies-text-end-does-not.test.ts, git diff --check, pnpm check:changed (core lane for touched files).

Out of scope / follow-ups

  • Broader end-to-end proof on ARM64 Docker + Telegram forum routing.
  • Any separate issue if compaction (assistantTexts) should reconcile silent streamed chunks differently from outbound delivery markers.

Changed files

  • CHANGELOG.md (modified, +1/-0)
  • src/agents/pi-embedded-subscribe.subscribe-embedded-pi-session.emits-block-replies-text-end-does-not.test.ts (modified, +26/-0)
  • src/agents/pi-embedded-subscribe.ts (modified, +3/-3)

Code Example

[agent/embedded] Skipping message_end safety send for text_end channel - content already delivered via text_end
[diagnostic] message processed: channel=telegram outcome=completed duration=12598ms
(no sendMessage ok entry anywhere in logs)
RAW_BUFFERClick to expand / collapse

Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

In 2026.5.4, Telegram outbound send never occurs in supergroup forum topics; every run completes with outcome=completed but no sendMessage ok appears in logs and reply never reaches Telegram.

Steps to reproduce

  1. Run OpenClaw 2026.5.4 via Docker on ARM64
  2. Configure Telegram channel with supergroup forum topics (groupPolicy: allowlist, requireMention: false on specific group)
  3. Send any message in a forum topic
  4. Observe: outcome=completed in logs but zero sendMessage ok entries
  5. Check dashboard: reply exists there but never delivered to Telegram

Expected behavior

In 2026.4.27, the agent posted replies to Telegram supergroup topics correctly. A [telegram] sendMessage ok log entry appeared after each completed run.

Actual behavior

No outbound send occurs. Every run ends with: "Skipping message_end safety send for text_end channel - content already delivered via text_end". Zero sendMessage ok entries confirmed via: docker logs openclaw 2>&1 | grep -E "(sendMessage|text_end|safety send)"

OpenClaw version

2026.5.4

Operating system

Ubuntu 24.04 (Docker container)

Install method

docker

Model

deepseek/deepseek-v4-flash

Provider / routing chain

openclaw -> deepseek API -> deepseek-v4-flash

Additional provider/model setup details

Direct DeepSeek official API, no proxy or gateway in between. Auth profile: deepseek:default with api_key mode. Config under models.providers.deepseek with baseUrl: https://api.deepseek.com

Logs, screenshots, and evidence

[agent/embedded] Skipping message_end safety send for text_end channel - content already delivered via text_end
[diagnostic] message processed: channel=telegram outcome=completed duration=12598ms
(no sendMessage ok entry anywhere in logs)

Impact and severity

Affected: All Telegram supergroup forum topic users on 2026.5.4 Severity: High - blocks all Telegram delivery Frequency: 100% reproducible, every single message Consequence: Agent processes and responds but user never receives reply in Telegram

Additional information

Last known good: 2026.4.27 First known bad: 2026.5.4 streaming.mode: "off" does not help - same behavior streaming.mode: "partial" - same behavior Related issue: #66459 (similar but intermittent, with thinking models - this is 100% reproducible with simple text responses)

extent analysis

TL;DR

The issue can be fixed by investigating and potentially modifying the logic related to the "Skipping message_end safety send for text_end channel" log entry, which seems to be incorrectly assuming content has been delivered.

Guidance

  • Review the changes made between versions 2026.4.27 and 2026.5.4 to identify any modifications that could be causing the "Skipping message_end safety send" behavior.
  • Investigate the text_end channel and its relationship with the message_end safety send to understand why it's being skipped.
  • Verify if the sendMessage API call is being made at all, and if not, why the code is not proceeding with the send operation.
  • Check the documentation and code for any specific handling of supergroup forum topics in Telegram that might be related to this issue.

Example

No specific code example can be provided without more context on the OpenClaw codebase, but the fix likely involves modifying the logic around the Skipping message_end safety send condition.

Notes

The issue seems to be specific to the 2026.5.4 version of OpenClaw and is 100% reproducible, which should help in isolating the cause. The fact that streaming.mode changes do not affect the behavior suggests the issue is not related to streaming.

Recommendation

Apply a workaround by temporarily modifying the code to force the sendMessage operation for supergroup forum topics, bypassing the "Skipping message_end safety send" check, until the root cause can be fully understood and a proper fix implemented.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

In 2026.4.27, the agent posted replies to Telegram supergroup topics correctly. A [telegram] sendMessage ok log entry appeared after each completed run.

#api#orchestration issue#cache issue#memory leak#API versioning

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING