openclaw - 💡(How to fix) Fix Telegram Responses Generated But Not Delivered - Silent Message Loss [1 participants]

title: Telegram Responses Generated But Not Delivered - Silent Message Loss labels: bug, telegram, channel-plugin, high-priority

Bug Report: Telegram Responses Generated But Not Delivered - Silent Message Loss

Severity: High - Intermittent message loss in production

Description: Assistant responses are generated successfully (visible in session logs) but fail to reach Telegram users. The issue is intermittent - some messages deliver successfully, others vanish without error. Users must re-ping to get responses.

Symptoms:

• Assistant responses appear in session history but not delivered to Telegram
• No corresponding telegram sendMessage ok log entries for failed messages
• No error surfaced to user or in logs
• Bot API is reachable (direct curl tests succeed)
• Intermittent - estimated 30-50% message loss rate
• User must send follow-up message to trigger delivery

Environment:

• OpenClaw version: 2026.4.2
• Node: 22.22.2
• OS: Linux 6.17.0-20-generic
• Channel: Telegram (bundled plugin)
• Gateway: Local loopback (127.0.0.1:18789)

What We Tested:

✅ Bot API reachable:

curl "https://api.telegram.org/bot<TOKEN>/getMe"
# Returns: {"ok":true,"result":{...}}

curl "https://api.telegram.org/bot<TOKEN>/sendMessage?chat_id=<CHAT_ID>&text=test"
# Returns: {"ok":true,"result":{...}}
# Message delivered successfully

✅ Gateway running:

openclaw gateway status
# RPC probe: ok
# State: active

✅ Session config correct:

• deliveryContext.channel: "telegram"
• deliveryContext.to: "telegram:<CHAT_ID>"
• lastChannel: "telegram"

❌ Log analysis shows:

{"subsystem":"telegram/network"} 
"fetch fallback: enabling sticky IPv4-only dispatcher (codes=ETIMEDOUT,ENETUNREACH)"

But this appears to be a red herring - direct API calls work fine.

Session Log Evidence:

Message generated (from sessions/*.jsonl):

{
  "type":"message",
  "id":"<MESSAGE_ID>",
  "timestamp":"2026-04-06T07:21:07.139Z",
  "message":{
    "role":"assistant",
    "content":[{"type":"toolCall","name":"browser",...}]
  }
}

But no delivery log entry:

# Expected (for successful messages):
{"subsystem":"gateway/channels/telegram"} "telegram sendMessage ok chat=<CHAT_ID> message=<MSG_ID>"

# Actual (for failed messages):
# Nothing - complete silence

Hypothesis: Message delivery queue/pipeline has a race condition or silent failure mode. Responses are generated but the handoff to Telegram channel plugin fails without logging or retry.

Impact:

• Users lose confidence in assistant reliability
• No way to know if message was sent
• Requires manual re-ping (poor UX)
• No visibility into failure rate

Suggested Debug Areas:

1. Message queue between agent turn completion and channel delivery
2. Telegram channel plugin delivery logic
3. Error handling in delivery pipeline (swallowing exceptions?)
4. Concurrent delivery attempts (race conditions?)
5. Memory pressure causing dropped messages?

Reproduction: Intermittent - appears random. No specific trigger identified. Occurs across multiple conversation turns.

Workaround:

• User re-pings when no response received
• Gateway restart occasionally helps (clears stuck state?)