Bug Description
When messages.tts.auto is set to "always" and the agent produces a long reply, the TTS audio is sent as a Telegram voice note with the full text as caption. If the caption exceeds Telegram's limit (~1024 chars for voice captions), the entire message is silently dropped — no error is logged, and the user receives nothing.
Steps to Reproduce
- Configure
messages.tts.auto: "always" with a TTS provider (e.g., OpenAI)
- Send the bot a message that triggers a long reply (>1024 chars)
- The bot generates audio + attaches the full reply text as voice caption
- Telegram rejects the message (caption too long for voice notes)
- No error is logged, no fallback delivery occurs
Expected Behavior
- OpenClaw should catch the Telegram API error (caption too long) and fall back to sending text + audio separately
- At minimum, the error should be logged so operators can diagnose delivery failures
- Ideally: auto-truncate caption or split into voice note + separate text message
Actual Behavior
- Message is silently dropped
- No entry in gateway logs
- User receives no reply at all
- Only discoverable by manually checking session history vs. delivered messages
Environment
- OpenClaw version: 2026.1.30
- Channel: Telegram (polling mode)
- TTS provider: OpenAI (gpt-4o-mini-tts)
streamMode: "partial"
replyToMode: "first"
Workaround
Set messages.tts.auto: "inbound" instead of "always" to only attach audio when replying to inbound voice notes. This reduces the frequency but doesn't fully prevent the issue for long voice-reply captions.
Suggested Fix
- Wrap Telegram
sendVoice in error handling that catches caption-length errors
- On failure: retry as separate
sendVoice (no caption) + sendMessage (full text)
- Log all delivery failures with context (message length, caption length, API error)
Bug Description
When
messages.tts.autois set to"always"and the agent produces a long reply, the TTS audio is sent as a Telegram voice note with the full text as caption. If the caption exceeds Telegram's limit (~1024 chars for voice captions), the entire message is silently dropped — no error is logged, and the user receives nothing.Steps to Reproduce
messages.tts.auto: "always"with a TTS provider (e.g., OpenAI)Expected Behavior
Actual Behavior
Environment
streamMode: "partial"replyToMode: "first"Workaround
Set
messages.tts.auto: "inbound"instead of"always"to only attach audio when replying to inbound voice notes. This reduces the frequency but doesn't fully prevent the issue for long voice-reply captions.Suggested Fix
sendVoicein error handling that catches caption-length errorssendVoice(no caption) +sendMessage(full text)