openclaw - 💡(How to fix) Fix Telegram: multiple reply blocks in one turn silently swallowed — only last message survives

Severity

Critical UX regression — directly impacts daily usability for Telegram DM users.

Problem

When the agent produces multiple text blocks in one turn (e.g., tool result summary → tool call → final answer), all intermediate text blocks are silently overwritten by the final block. The user only sees the last message. Previous messages are edited out of existence.

This is NOT about streaming preview noise. This is about finalized, meaningful content being destroyed.

Steps to reproduce

1. Run OpenClaw 2026.5.26 with Telegram, streaming.mode: "partial"
2. Ask a question that requires multiple tool calls with intermediate explanations
3. Agent produces: text block A → tool call → text block B → tool call → text block C (final)
4. User sees: only text block C. Blocks A and B are gone — edited into C or deleted.

Expected behavior

Each meaningful text block should be delivered as a separate Telegram message. The user should see all text the agent produced, not just the final one.

Actual behavior

• Text block A is sent as a preview message
• Text block B overwrites A (editMessageText)
• Text block C overwrites B (editMessageText)
• Final state: only C is visible in chat
• A and B — summaries, findings, explanations — are permanently lost

Impact

• Daily Telegram DM users experience this on every multi-tool turn
• Agent appears to "forget" or "skip" intermediate reasoning
• User misses potentially important information the agent explicitly chose to communicate
• Web UI does NOT have this problem — all blocks are visible there

Environment

• OpenClaw: 2026.5.26 (10ad3aa)
• Channel: Telegram DM
• Config: streaming.mode: "partial", streaming.preview.toolProgress: false

Root cause (from code inspection)

• bot-message-dispatch.ts → onAssistantMessageStart only rotates the message lane when answerLane.finalized === true
• Intermediate text blocks (isFinal=false) update the preview in place via streamText() in lane-delivery-text-deliverer.ts
• They are never committed as real messages before the next block overwrites them
• Regression from PR #32890 which removed archive + forceNewMessage logic to fix inter-tool text leak (#25592)

Related

• #87326 — same root cause, filed earlier today
• #84885 — P1 beta-blocker, related streaming spam issue
• #32890 — the PR that introduced this regression
• #25592 — the original issue #32890 was trying to fix

Suggested fix

Restore the archive + forceNewMessage behavior for finalized text blocks (isFinal=true or block-kind text), while keeping the current behavior for transient tool-progress narration. The key distinction: if the agent explicitly wrote something as a meaningful text block (not just "running tool..."), it should be committed as a real message before the next block starts.