Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

Yes

Summary

Telegram streaming.mode="partial" can emit many visible sendMessage previews for a single inbound turn instead of keeping one draft preview and one final reply.

Steps to reproduce

1. Run OpenClaw 2026.5.19 with Telegram polling enabled and draft/partial streaming enabled.
2. Send a Telegram DM that produces a long or repeatedly-updated partial stream.
3. Observe the Telegram chat and gateway log while the agent turn is still in progress.
4. A single inbound user message can result in many visible bot messages before the durable final send.

Expected behavior

Partial streaming should maintain at most one mutable visible draft per active turn, then finalize or replace it with the durable final reply. Draft overflow should not roll over into retained visible messages before finalization.

Actual behavior

On a local 2026.5.19 incident, one Telegram DM turn produced a burst of visible Telegram sends in the same chat:

/tmp/openclaw/openclaw-2026-05-21.log
2026-05-21T15:07:45+07:00 telegram sendMessage ok chat=<redacted-dm> message=24320
2026-05-21T15:07:46+07:00 telegram sendMessage ok chat=<redacted-dm> message=24321
2026-05-21T15:07:47+07:00 telegram sendMessage ok chat=<redacted-dm> message=24322
2026-05-21T15:07:48+07:00 telegram sendMessage ok chat=<redacted-dm> message=24323
2026-05-21T15:07:49+07:00 telegram sendMessage ok chat=<redacted-dm> message=24324
2026-05-21T15:08:35+07:00 telegram sendMessage ok chat=<redacted-dm> message=24325
2026-05-21T15:10:27+07:00 telegram sendMessage ok chat=<redacted-dm> message=24327
2026-05-21T15:10:28+07:00 telegram sendMessage ok chat=<redacted-dm> message=24328
2026-05-21T15:10:31+07:00 telegram sendMessage ok chat=<redacted-dm> message=24329
2026-05-21T15:10:50+07:00 telegram sendMessage ok chat=<redacted-dm> message=24330
2026-05-21T15:10:50+07:00 telegram sendMessage ok chat=<redacted-dm> message=24331
2026-05-21T15:10:51+07:00 telegram sendMessage ok chat=<redacted-dm> message=24332
2026-05-21T15:10:53+07:00 telegram outbound send ok accountId=default chatId=<redacted-dm> messageId=24333 operation=sendMessage deliveryKind=text chunkCount=1

The durable outbound path only logged the final send (telegram outbound send ok ... messageId=24333). The earlier channels/telegram sendMessage ok entries appear to be draft/preview transport sends, not durable final delivery ledger entries.

OpenClaw version

2026.5.19

Operating system

macOS 26 / Darwin arm64

Install method

Global OpenClaw gateway managed by launchd (ai.openclaw.gateway)

Model

OpenRouter/OpenAI GPT-5 family route in the affected session; exact final model for every preview send is NOT_ENOUGH_INFO.

Provider / routing chain

Telegram polling -> OpenClaw gateway -> embedded agent -> OpenRouter/OpenAI route

Additional provider/model setup details

The local mitigation was to set both:

{
  "channels.telegram.streaming.mode": "off",
  "channels.telegram.accounts.default.streaming.mode": "off"
}

After restart, openclaw channels status --json reported Telegram polling connected and event loop not degraded.

Logs, screenshots, and evidence

Source-level path of concern:
- extensions/telegram/src/draft-stream.ts:206 handles renderedText.length > maxChars.
- extensions/telegram/src/draft-stream.ts:207-223 retains the old preview and resets to a new message when lastDeliveredText.length > deliveredTextOffset.
- extensions/telegram/src/draft-stream.ts:225-233 splits an oversized first rendered preview by recursively sending chunks.

Current behavior allows the overflow/retention path while streamState.final is false, so non-final partial previews can become multiple retained visible Telegram messages.

Related outbound paths:
- extensions/telegram/src/draft-stream.ts:125-135 sends preview messages through api.sendMessage.
- src/channels/turn/durable-delivery.ts and src/channels/message/send.ts handle durable final delivery.

flowchart TD
  A[Telegram inbound DM] --> B[Agent turn starts]
  B --> C[Partial draft stream update]
  C --> D{Rendered preview > Telegram max?}
  D -- no --> E[edit existing preview]
  D -- yes, non-final --> F[roll over / send new visible preview]
  F --> C
  B --> G[Final assistant reply]
  G --> H[Durable final send]

  classDef bad fill:#ffd6d6,stroke:#cc3333,color:#111;
  class F bad;

Impact and severity

Affected: Telegram users with partial streaming enabled.
Severity: High / beta blocker for Telegram reliability. The user sees repeated bot messages for one turn and may believe the agent is looping.
Frequency: Observed during the local 2026.5.19 Eva incident; deterministic unit-level risk exists from the overflow code path.
Consequence: Duplicate visible replies, confusing chat state, and extra outbound Telegram sends.

Additional information

Related but not identical: #75498 covers Web UI-only final delivery and partial streaming ambiguity. This issue is the narrower visible-spam/preview-rollover failure mode: non-final draft overflow should not retain and send multiple visible preview messages.

Suggested fix shape: gate the rollover/chained-message path on finalization. For non-final partial previews, keep a single preview message and truncate/coalesce the preview until the final response is ready; only split/retain overflow pages for the final reply.