#Telegram is trimming messages

1 messages · Page 1 of 1 (latest)

brave star
#

Telegram is trimming messages without any reason. Tried both partial and final streaming didn't fix.

fringe flameBOT
#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> âś… Mark Solution

oblique ironBOT
# brave star Telegram is trimming messages without any reason. Tried both partial and final s...

First thing: what version are you on? Please paste:

openclaw --version

Telegram has a hard ~4096 char message limit. OpenClaw is supposed to chunk Telegram replies (channels.telegram.textChunkLimit, default 4000), so if final replies are being cut mid-message that smells like either a version-specific bug, formatting expanding past the limit, or a Telegram API error during the later chunks.

Two quick things to try/check:

{
  channels: {
    telegram: {
      textChunkLimit: 3500,
      chunkMode: "newline",
oblique ironBOT
brave star
#

OpenClaw 2026.5.12 (f066dd2)

oblique ironBOT
# brave star OpenClaw 2026.5.12 (f066dd2)

Thanks. 2026.5.12 is current stable, so this is worth narrowing down rather than assuming an old-version issue.

A useful next split:

  1. If Telegram shows only one message and it ends around 4096 chars, chunking is not being applied on that path.
  2. If it sends the first chunk but not later chunks, Telegram is probably rejecting a later formatted chunk and the logs should show it.
  3. If the preview edits correctly but the final message is shorter, that points at final delivery rather than streaming.

Please run this once and reproduce:

OPENCLAW_DIAGNOSTICS=telegram.http,telegram.payload openclaw gateway

If you run the gateway as a daemon instead, set the same env for the service or temporarily stop it and run foreground. Then share the telegram http error lines from:

oblique ironBOT
# brave star OpenClaw 2026.5.12 (f066dd2)
openclaw logs --follow

Also run:

openclaw doctor

One nuance: chunkMode / scalar streaming are accepted, but doctor may modernize them into the newer channels.telegram.streaming.* shape. If textChunkLimit: 3500 still trims on 2026.5.12, the logs are the next high-signal thing.

brave star
#

🦞 OpenClaw 2026.5.12 (f066dd2)
Gateway online—please keep hands, feet, and appendages inside the shell at all times.

│
â—‡
19:05:38 [gateway] loading configuration…
19:05:38 [gateway] resolving authentication…
19:05:38 [gateway] starting...
19:05:40 [gateway] starting HTTP server...
19:05:40 [health-monitor] started (interval: 300s, startup-grace: 60s, channel-connect-grace: 120s)
19:05:50 [shutdown] started: gateway startup failed
19:05:50 [gmail-watcher] gmail watcher stopped
19:05:50 [shutdown] completed cleanly in 7ms
19:05:50 [gateway] already running under launchd; existing gateway is healthy, leaving it in control
rodrigo@Rodrigos-MacBook-Pro ~ %


OPENCLAW_DIAGNOSTICS=telegram.http,telegram.payload openclaw gateway

oblique ironBOT
# brave star 🦞 OpenClaw 2026.5.12 (f066dd2) Gateway online—please keep hands, feet, and a...

That output means the foreground gateway did not take over. Your existing launchd gateway stayed in control, so OPENCLAW_DIAGNOSTICS=... openclaw gateway never applied to the process handling Telegram.

Easiest path: enable diagnostics in config instead, restart the launchd gateway, then reproduce:

{
  diagnostics: {
    flags: ["telegram.http", "telegram.payload"]
  }
}

Then:

openclaw gateway restart
oblique ironBOT
oblique ironBOT
brave star
#

OpenClaw version: 2026.5.12 (f066dd2)

Current Telegram config:

  • channels.telegram.textChunkLimit: unset, so default likely 4000
  • channels.telegram.chunkMode: unset
  • channels.telegram.streaming: {"mode":"partial","preview":{"toolProgress":false},"progress":{"toolProgress":false}}

Schema note:

  • channels.telegram.textChunkLimit exists.
  • channels.telegram.streaming.mode exists.
  • channels.telegram.streaming.chunkMode exists.
  • channels.telegram.chunkMode lookup returns “config schema path not found” on this build, though docs mention top-level chunkMode.

Repro:
A normal final Telegram reply around 2026-05-15 19:04 America/Sao_Paulo was visibly truncated in Telegram after ~2 list items, far below Telegram’s 4096-char hard limit. The full assistant answer was only around ~1.5–1.7k chars.

Log excerpt around repro, sanitized:
2026-05-15T19:04:34.918-03:00 info gateway/channels/telegram/inbound Inbound message -> @rlf_claw_bot (direct, 95 chars)
2026-05-15T19:05:24.254-03:00 info gateway/channels/telegram/inbound Inbound message -> @rlf_claw_bot (direct, image/jpeg, 11 chars)
2026-05-15T19:05:57.816-03:00 info gateway/ws res âś“ message.action 872ms channel=telegram
2026-05-15T19:06:05.682-03:00 info gateway/ws res âś“ message.action 426ms channel=telegram

Important: I do NOT see a Telegram Bot API error around the clipped final reply — no 400, no “message is too long”, no parse error. Also I don’t see a clear sendMessage log line for the clipped final reply itself, only later message.action successes from manual workaround sends.

Doctor summary:

  • No Telegram delivery-specific doctor error.
  • Warnings include legacy openai-codex/* model refs needing rewrite to openai/*, Telegram first-time setup/allowlist warnings, one orphan transcript, stale session route state, and bootstrap MEMORY.md truncation.
  • Security: no channel security warnings.
  • Plugins: loaded 70, errors 0.
  • Skills: eligible 59, missing requirements 0.
oblique ironBOT
# brave star OpenClaw version: 2026.5.12 (f066dd2) Current Telegram config: - channels.teleg...

That’s a much better repro. Since the full answer is only ~1.5–1.7k chars and there’s no Bot API error, textChunkLimit is probably not the active problem. This looks like the Telegram partial preview/finalization path is leaving a partial preview visible instead of replacing it with the full final text.

Two practical next steps:

  1. Workaround/test: turn Telegram preview streaming fully off using the current schema shape:
{
  channels: {
    telegram: {
      streaming: {
        mode: "off"
      }
    }
  }
}