Problem
When a user pastes a long message into Telegram, the Telegram client splits it at ~4096 characters and sends it as multiple updates. Hermes has text batching (_enqueue_text_event at telegram.py:2153) that buffers rapid successive messages and concatenates them before dispatching.
However, the default batch delay is 0.6 seconds (HERMES_TELEGRAM_TEXT_BATCH_DELAY_SECONDS). If the second chunk arrives more than 0.6s after the first (slow network, large message, Telegram server delay), the first chunk is already flushed and dispatched. The second chunk then:
- Arrives as a separate message
- Gets queued behind the agent's in-progress response to the first chunk
- Is never processed as part of the original message — the agent only sees the first half
User report
User pasted a long response from another tool. The message was split by Telegram into two parts. Hermes only processed the first part and responded based on incomplete information. The second part was silently lost.
Existing mitigation
The batching at telegram.py:2153-2180 correctly handles the common case (chunks arriving within 0.6s). The issue is edge cases where chunks are delayed.
Suggested fixes
-
Increase default delay — 0.6s may be too tight for large messages on slow connections. 1.0-1.5s would catch more splits with minimal latency impact.
-
Character-aware batching — if the first chunk is exactly ~4096 chars (Telegram's split point), wait longer for a continuation since a split is almost certain.
-
Configurable per-user — HERMES_TELEGRAM_TEXT_BATCH_DELAY_SECONDS is already an env var but users don't know about it. Document it in the Telegram setup guide.
Info
- Telegram's message split point: 4096 characters
- Default batch delay: 0.6s (
HERMES_TELEGRAM_TEXT_BATCH_DELAY_SECONDS)
- No max batch message count limit
- Code:
gateway/platforms/telegram.py:2153-2180
Problem
When a user pastes a long message into Telegram, the Telegram client splits it at ~4096 characters and sends it as multiple updates. Hermes has text batching (
_enqueue_text_eventattelegram.py:2153) that buffers rapid successive messages and concatenates them before dispatching.However, the default batch delay is 0.6 seconds (
HERMES_TELEGRAM_TEXT_BATCH_DELAY_SECONDS). If the second chunk arrives more than 0.6s after the first (slow network, large message, Telegram server delay), the first chunk is already flushed and dispatched. The second chunk then:User report
User pasted a long response from another tool. The message was split by Telegram into two parts. Hermes only processed the first part and responded based on incomplete information. The second part was silently lost.
Existing mitigation
The batching at
telegram.py:2153-2180correctly handles the common case (chunks arriving within 0.6s). The issue is edge cases where chunks are delayed.Suggested fixes
Increase default delay — 0.6s may be too tight for large messages on slow connections. 1.0-1.5s would catch more splits with minimal latency impact.
Character-aware batching — if the first chunk is exactly ~4096 chars (Telegram's split point), wait longer for a continuation since a split is almost certain.
Configurable per-user —
HERMES_TELEGRAM_TEXT_BATCH_DELAY_SECONDSis already an env var but users don't know about it. Document it in the Telegram setup guide.Info
HERMES_TELEGRAM_TEXT_BATCH_DELAY_SECONDS)gateway/platforms/telegram.py:2153-2180