[Bug]: Telegram inbound long-message aggregation fails when first fragment is below near-limit threshold (~4000 chars) #26237
Description
Summary
Inbound Telegram long-message aggregation is content-dependent and sometimes fails when the first Telegram-split fragment is below the current near-limit threshold (observed around ~3900 chars), causing tail fragments to be processed as separate messages/reports.
Steps to reproduce
- Use the Telegram channel with OpenClaw (same chat/session, no model change needed).
- Send one long plain text message that Telegram splits into multiple parts (single paste/send action).
- Use a structured message (Markdown-like content, headings
###, heredoc/EOF, long sections), so Telegram splits earlier. - Observe that OpenClaw replies to each fragment separately (e.g., "Part 1", "Part 2", "Part 3"...), instead of treating it as one inbound message.
- Repeat with a different long message where the first Telegram fragment is slightly longer (observed ~4100 chars) and compare behavior.
Expected behavior
OpenClaw should aggregate sequential Telegram fragments of a single long pasted message into one inbound message and process it once (one run / one report), regardless of small content-dependent differences in Telegram split position.
Actual behavior
OpenClaw intermittently processes Telegram-split fragments as separate inbound messages. In my repro, the bot produced separate replies for Part 1, Part 2, Part 3, and Part 4 (aggregation did not trigger). This depends on message content and the resulting first-fragment length.
OpenClaw version
2026.2.23
Operating system
Ubuntu 24.04
Install method
No response
Logs, screenshots, and evidence
### Observed behavior (user-visible)
- Same long-message workflow, same Telegram channel/session.
- **Model does not matter** (reproduced independently of selected model).
- One long message was split by Telegram into **4 parts**, and OpenClaw replied separately to each part.
- Bot explicitly reported:
- "Part 1 received..."
- "Part 2 received..."
- "Part 3 received..."
- "Part 4 received..."
- Final conclusion: aggregation did not work.
### Diagnostic mode results (bot-side content inspection)
I enabled a diagnostic mode where the bot reports approximate character count and whether the message is a complete message or a split fragment.
Results:
- **~8200 chars** message: bot received it as a whole (either Telegram did not split, or OpenClaw successfully aggregated).
- A test case that **did aggregate** had first fragment around **~4100 chars**.
- A test case that **did NOT aggregate** had first fragment around **~3900 chars**.
- Both cases started with the same text prefix (not a command, no `/` at start), and both included `EOF` in heredoc content.
### Why this looks like a threshold issue
Telegram split position changes depending on content (headings, line breaks, markdown-like structure, heredoc blocks, etc.).
If the first fragment lands below the current "near-limit" threshold (apparently around 4000), inbound aggregation may not start at all, and the tail is processed as a separate message.
### Relevant implementation context (from current code)
Current Telegram inbound aggregation uses a "near-limit" heuristic with a start threshold around **4000 chars** (plus timing / sequential checks).Impact and severity
No response
Additional information
No response