Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix [Bug]: Telegram responses are truncated or do not show up [1 pull requests, 1 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#43771•Fetched 2026-04-08 00:18:15
View on GitHub
Comments
0
Participants
1
Timeline
4
Reactions
0
Author
augmentedstartupsaugmentedstartups
Participants
augmentedstartupsaugmentedstartups
Timeline (top)
labeled ×2cross-referenced ×1subscribed ×1

When i send a message via telegram the response is either truncated or doesnt show up at all. It use to work before. The responses still show up on the web UI.

Root Cause

When i send a message via telegram the response is either truncated or doesnt show up at all. It use to work before. The responses still show up on the web UI.

Fix Action

Fixed

PR fix notes

PR #43787: fix(telegram): prefer active preview for matching tool-call finals

Description (problem / solution / changelog)

Summary

  • Problem: Telegram DM streaming could apply a final answer to an older archived boundary preview instead of the current active preview after tool/skill boundaries.
  • Why it matters: users can see stale/truncated latest bubbles, or think the latest response disappeared when the final lands on an older message.
  • What changed: final-lane mapping now prefers the active preview when final text matches the active snapshot and does not match the archived snapshot; archived FIFO behavior is kept for true multi-final boundary mapping.
  • What did NOT change (scope boundary): no change to provider dispatching, send chunking, or non-Telegram channels.

Change Type (select all)

  • Bug fix
  • Feature
  • Refactor
  • Docs
  • Security hardening
  • Chore/infra

Scope (select all touched areas)

  • Gateway / orchestration
  • Skills / tool execution
  • Auth / tokens
  • Memory / storage
  • Integrations
  • API / contracts
  • UI / DX
  • CI/CD / infra

Linked Issue/PR

  • Closes #43771
  • Related #d4ab73174

User-visible / Behavior Changes

  • In Telegram DM streaming flows with tool-call boundaries, finals now resolve to the currently streamed preview when that preview text matches the final.
  • This avoids leaving a stale/truncated latest preview bubble while updating an older boundary message.

Security Impact (required)

  • New permissions/capabilities? (No)
  • Secrets/tokens handling changed? (No)
  • New/changed network calls? (No)
  • Command/tool execution surface changed? (No)
  • Data access scope changed? (No)
  • If any Yes, explain risk + mitigation:

Repro + Verification

Environment

  • OS: macOS (local dev)
  • Runtime/container: Node 22+, pnpm
  • Model/provider: n/a (unit tests)
  • Integration/channel (if any): Telegram
  • Relevant config (redacted): n/a

Steps

  1. Simulate a streamed Telegram answer that crosses a tool boundary (archived boundary preview + active preview).
  2. Deliver a final that matches the active preview text.
  3. Verify the final edit target is the active preview ID, not the archived boundary ID.

Expected

  • Final is applied to the active preview bubble for the current assistant segment.

Actual

  • ✅ With this patch, active preview is finalized and the boundary archive remains untouched.

Evidence

  • Failing test/log before + passing after
  • Trace/log snippets
  • Screenshot/recording
  • Perf numbers (if relevant)

Validation commands run locally:

  • pnpm vitest src/telegram/lane-delivery.test.ts src/telegram/bot-message-dispatch.test.ts
    • Result: 2 passed, 74 passed tests total.

Human Verification (required)

What you personally verified (not just CI), and how:

  • Verified scenarios:
    • Added regression unit test in src/telegram/lane-delivery.test.ts to cover boundary archive + active preview final selection.
    • Confirmed existing Telegram dispatch tests still pass.
  • Edge cases checked:
    • Active snapshot/final prefix-match logic only bypasses archive when archive snapshot does not also match.
  • What you did not verify:
    • Live Telegram Bot API run against a real chat.

Review Conversations

  • I replied to or resolved every bot review conversation I addressed in this PR.
  • I left unresolved only the conversations that still need reviewer or maintainer judgment.

If a bot review conversation is addressed by this PR, resolve that conversation yourself. Do not leave bot review conversation cleanup for maintainers.

Compatibility / Migration

  • Backward compatible? (Yes)
  • Config/env changes? (No)
  • Migration needed? (No)
  • If yes, exact upgrade steps:

Failure Recovery (if this breaks)

  • How to disable/revert this change quickly:
    • Revert commit cab7d92dd.
  • Files/config to restore:
    • src/telegram/lane-delivery-text-deliverer.ts
    • src/telegram/lane-delivery.test.ts
  • Known bad symptoms reviewers should watch for:
    • Finals mapping to the wrong preview ID in DM tool-boundary flows.

Risks and Mitigations

  • Risk:
    • Snapshot matching could choose active preview in ambiguous text-overlap cases.
  • Mitigation:
    • Preference only activates when active snapshot matches and archived snapshot does not; existing archived FIFO behavior remains otherwise.

Changed files

  • src/telegram/lane-delivery-text-deliverer.ts (modified, +22/-1)
  • src/telegram/lane-delivery.test.ts (modified, +70/-0)
RAW_BUFFERClick to expand / collapse

Bug type

Regression (worked before, now fails)

Summary

When i send a message via telegram the response is either truncated or doesnt show up at all. It use to work before. The responses still show up on the web UI.

Steps to reproduce

I asked the Agent to do a particular task. I thinks happens when it calls a skill or a tool. I havent change anything . It only started happening after an update.

Expected behavior

The full message should show via telegram.

Actual behavior

Truncated messages on telegream

OpenClaw version

2026.3.8

Operating system

MacOS Sequoia

Install method

No response

Model

All models

Provider / routing chain

openclaw->macMini->telegram

Config file / key location

No response

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Impact and severity

No response

Additional information

No response

extent analysis

Fix: Split / Escape Telegram Bot Messages (≤ 4096 chars)

The regression is caused by the Telegram API limit (4 KB per sendMessage) and a recent change that started sending raw Markdown‑V2 text. When the payload exceeds the limit or contains un‑escaped characters, Telegram silently drops the tail of the message, giving you “truncated” output.

The fix is to (1) escape Markdown‑V2 correctly and (2) automatically chunk any payload that exceeds 4096 bytes before calling bot.send_message.

1️⃣ Update the Telegram helper used by OpenClaw

Add a small utility module (e.g., telegram_utils.py) and replace the old send_message call with the new wrapper.

# telegram_utils.py
import re
from typing import List
from telegram import Bot, ParseMode

# Telegram caps messages at 4096 characters (UTF‑8 bytes)
MAX_TG_LEN = 4096

def _escape_markdown(text: str) -> str:
    """
    Escape characters required by MarkdownV2.
    See: https://core.telegram.org/bots/api#markdownv2-style
    """
    escape_chars = r'_*[\]()~`>#+-=|{}.!'
    return re.sub(f'([{re.escape(escape_chars)}])', r'\\\1', text)

def _chunk_text(text: str, limit: int = MAX_TG_LEN) -> List[str]:
    """
    Split `text` into chunks that fit Telegram's limit.
    Prefer splitting on newlines or spaces to avoid breaking words.
    """
    chunks = []
    while text:
        if len(text) <= limit:
            chunks.append(text)
            break

        # Look for a safe split point within the limit
        split_at = text.r

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

The full message should show via telegram.

#api#ssr#installation#tensor shape#autograd error#pipeline error#runtime error#dependency conflict#environment setup#docker error

Still need to ship something?

×6

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

Back to top recommendations

TRENDING