#Telegram inbound messages fail with “Something went wrong” despite valid config

1 messages · Page 1 of 1 (latest)

livid nebula
#

Telegram is fully configured and enabled (botToken, dmPolicy, allowFrom all present), and the bot can send messages back to Telegram, but any inbound Telegram message returns:

"Something went wrong while processing your request. Please try again, or use /new to start a fresh session."

This still happens after token rotation, gateway restart, machine restart, and /new. Config health looks clean. No Telegram session appears to be created. Seems like a Telegram runtime/session bootstrap bug rather than a bad config.

sharp abyssBOT
#

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

stray steppeBOT
vague joltBOT
#

Let me verify this against the docs and source so I don’t guess.

#

I checked the source, and that exact Telegram text is the shared agent run failed fallback, not a Telegram-specific config failure.

So if outbound Telegram sends work, inbound is probably reaching the gateway, then dying during run/session bootstrap before a session gets committed. The “no Telegram session appears” part fits that.

First, what does this print?

openclaw --version

Then on the gateway host, run this and send one Telegram message while logs are tailing:

openclaw status --all
openclaw models status
openclaw channels status --probe
# 
openclaw logs --follow

Please paste the log lines from that failed inbound attempt. That will usually show whether it’s:

  • model/auth on the gateway host
  • session store / transcript path issue
  • bootstrap/session corruption

If the logs show an unclassified exception every time, I’d treat it as a real bug and file it with version + stack trace here:
https://github.com/openclaw/openclaw/issues

Docs:
https://docs.openclaw.ai/help/faq
https://docs.openclaw.ai/channels/telegram
https://docs.openclaw.ai/channels/troubleshooting

livid nebula
#

thank you it worked

vague joltBOT
#

Glad that helped! 🎉

If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution.
This helps Answer Overflow index the solution for future users.

midnight oxide
#

Telegram Bot Not Receiving Messages When Session Closed

Environment:
• OS: Linux (VPS)
• Channel: Telegram
• Setup: Multiple agents with Telegram bot bindings

Problem:
Telegram bots stop polling for new messages when their session ends (status: "done"). This breaks agent-to-agent communication via sessions_send and makes bots unresponsive to user messages until the next heartbeat.

Steps to Reproduce:

  1. Create agent with Telegram bot binding
  2. Send message to bot → bot responds → session ends (status: "done")
  3. Send another message to bot
  4. Expected: Bot receives message immediately
  5. Actual: Bot doesn't receive message until next heartbeat (5+ minutes later)

Current Behavior:

• ✅ Bot polls when session is active
• ❌ Bot stops polling when session closes
• ❌ New messages not received until heartbeat wakes session
• ❌ sessions_send to closed session fails silently

Expected Behavior:

• ✅ Bot continuously polls Telegram API regardless of session state
• ✅ New messages trigger new session immediately
• ✅ sessions_send wakes target session if closed

Workarounds Tried:

  1. ✅ Heartbeat every 5 min → too slow for real-time
  2. ✅ Manual /start before each message → annoying
  3. ❌ sessions_send to wake session → doesn't work

Use Case:
Multi-agent workflow where CMO coordinates with Copywriter, Content Strategist, and CRO Specialist via sessions_send. CMO sends task → agent responds → CMO session closed → agent's response lost.

Proposed Solution:
Enable continuous Telegram polling for agent bots independent of session state, similar to how traditional Telegram bots work (long polling or webhooks).

Is there a config option to enable continuous Telegram polling? Or is this a feature request for the roadmap?

vague joltBOT
#

I’m going to verify this in the docs/source, because this sounds like either a real bug or a misunderstanding around bindings, and I don’t want to hand-wave it.

#

Short answer: there isn’t a config option for this, because Telegram polling is already supposed to be gateway-owned and continuous.

I checked the docs/source, and the intended behavior is:

  • Telegram is owned by the gateway process, not by an individual chat session
  • Long polling is the default
  • a session being done should not stop Telegram getUpdates

So if polling really pauses until heartbeat, I’d treat that as a bug, not expected behavior.

One important nuance: sessions_send targets an existing session, it is not a channel transport wake mechanism. So if you’re expecting it to recreate/wake a brand-new Telegram chat session from nothing, that part is not the right tool.

First thing, what does this print?

openclaw --version
#

Then I’d grab:

openclaw status --all
openclaw channels status --probe
openclaw logs --follow

and send a Telegram message after the session shows done. If this is the bug you described, the logs should show the polling loop stalling/restarting or dropping transport state.

Docs:
https://docs.openclaw.ai/channels/telegram
https://docs.openclaw.ai/help/faq
https://docs.openclaw.ai/channels/troubleshooting

If you can reproduce it reliably, please file it here with version + logs + binding setup:
https://github.com/openclaw/openclaw/issues

#

If you want, paste openclaw --version plus the channels status --probe / log snippet here and I can help narrow down whether it’s polling transport vs session-routing.

midnight oxide
# vague jolt Short answer: **there isn’t a config option for this**, because Telegram polling...

Follow-up to your response:

Thanks for confirming this is likely a bug! I've verified the behavior you described:

What I confirmed:

• ✅ openclaw channels status --probe shows mode:polling, running, works
• ✅ curl getUpdates returns empty (messages consumed)
• ❌ Messages NOT in agent session history
• ❌ No response sent to user

Version & Setup:

OpenClaw: 2026.4.10 (44e5b62)
OS: Linux 6.8.0-106-generic, Node v22.22.2
Setup: 9 Telegram accounts, multi-agent bindings
Specific observations:

  1. Before restart: Bot receives messages but generates empty responses (163k input tokens, 0 output tokens)
  2. After restart: Polling works, messages consumed, but routing completely broken

Questions:

  1. Is the "empty response" issue (0 output tokens) related to the routing bug, or separate?
  2. Should I file one GitHub issue for both problems, or two separate issues?
  3. Any specific logs you need beyond openclaw logs --follow during message send?

The binding setup uses accountId matching per agent. Is there a known issue with multi-account routing after gateway restart?

vague joltBOT
#

Let me tighten that up a bit and sanity-check whether there’s anything known around multi-account Telegram routing before you post it.

#

Yep, I’d post it, but I’d split it into 2 GitHub issues.

From what you described, they look like different layers:

  1. Empty response / 0 output tokens
    That sounds like the run is starting, burning context, then hitting an empty/incomplete-turn path.

  2. Post-restart Telegram routing broken
    getUpdates consuming messages but nothing landing in session history is earlier in the pipeline, so that looks more like routing/binding/account resolution.

One extra thing I’d include: with 9 Telegram accounts, make sure you have an explicit Telegram default account set. The docs call this out for multi-account setups:
https://docs.openclaw.ai/gateway/configuration-reference
https://docs.openclaw.ai/channels/telegram
https://docs.openclaw.ai/cli/agents

For the routing issue, I’d attach:

#
  • openclaw --version
  • openclaw status --all
  • openclaw channels status --probe
  • openclaw agents bindings --json
  • redacted channels.telegram config
  • openclaw logs --follow covering:
    • gateway startup
    • one inbound message after restart

If you want, I can help you turn that into two clean issue bodies with titles, but the short answer is: yes, post it, and split it.

#

Based on that, I’d treat them as probably separate:

  1. 163k input / 0 output = the run is starting, then hitting an empty/incomplete-turn path.
  2. Messages consumed by Telegram but never appearing in session history after restart = routing/binding/account resolution earlier in the pipeline.

So yes, I’d file 2 GitHub issues, not 1. That’ll make triage a lot cleaner.

For the routing issue, I’d include these too, not just openclaw logs --follow:

openclaw --version
openclaw status --all
openclaw channels status --probe
openclaw agents bindings --json
openclaw doctor