Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

After a gateway restart, the Telegram channel stopped responding even though Telegram updates were still being received and stored by OpenClaw.

The root cause appears to be a Telegram ingress event that remains in a claimed state indefinitely. Because Telegram processing is serialized, a single stuck event prevents all subsequent updates from being processed.

This was observed on three separate OpenClaw installations.

Steps to reproduce

1. Start a Telegram conversation with the OpenClaw bot.

2. Send one or more messages and wait for a normal response.

3. Trigger a Gateway restart (for example during configuration changes, updates, new feature request, etc.).

4. Continue the existing Telegram conversation after the restart.

5. In some cases, the bot stops responding to new Telegram messages even though:

   • Telegram polling is still running.
   • New updates are successfully consumed from Telegram.
   • Updates are inserted into channel_ingress_events.
   • The Gateway reports no visible errors.

Observed behavior:
A Telegram update may remain stuck in the ingress queue and block subsequent updates. New messages continue to accumulate in channel_ingress_events with status pending, while one event remains claimed indefinitely.

Expected behavior

After a Gateway restart, any interrupted Telegram update should either:

• be safely resumed, or
• be automatically released/recovered after a timeout,

so that new Telegram messages continue to be processed normally.

Actual behavior

Telegram bot stops replying.
getUpdates from Telegram API confirms new messages are being received.
New updates continue to be inserted into channel_ingress_events.
The queue accumulates pending events.
One event remains permanently in claimed status.
Gateway logs show Telegram provider starting normally.
No obvious Telegram errors appear in the logs.
Restarting the gateway does not resolve the issue.

Example queue state:

SELECT queue_name,status,COUNT(*)
FROM channel_ingress_events
GROUP BY queue_name,status;

Example result:

["telegram","default"]|claimed|1
["telegram","default"]|pending|18

Example stuck record:

event_id = 0000000934725214
status = claimed
claim_owner = 8:4d532944-092e-42b8-a6bc-8249b7a8e988

A Telegram event can remain indefinitely in claimed state, preventing all subsequent updates from being processed until manual database intervention is performed.

OpenClaw version

2026.6.1

Operating system

Ubuntu Server 26.04

Install method

docker

Model

deepseek-v4-flash

Provider / routing chain

telegram -> openclaw gateway

Additional provider/model setup details

No response

Logs, screenshots, and evidence

### Logs

Gateway startup appears normal:

[telegram] [default] starting provider (@XXX)
[telegram] [diag] isolated polling ingress started spool=/home/node/.openclaw/telegram/ingress-spool-default

No Telegram-related errors are logged after startup.

Telegram updates are consumed successfully:

curl https://api.telegram.org/bot<TOKEN>/getUpdates

returns an empty result while the Gateway is running, indicating that OpenClaw is polling and consuming updates.

Queue state after the failure:

SELECT queue_name,status,COUNT(*)
FROM channel_ingress_events
GROUP BY queue_name,status;

Result:

["telegram","default"]|claimed|1
["telegram","default"]|pending|18

The blocked event remained permanently in `claimed` state while all newer Telegram messages accumulated as `pending`.

Example stuck event:

event_id: 0000000934725214
status: claimed
attempts: 0
claim_owner: 8:4d532944-092e-42b8-a6bc-8249b7a8e988

After manually clearing the blocked event and creating a new Telegram session with `/new`, Telegram functionality resumed normally.

Impact and severity

What makes this problematic
The Telegram provider continues to ingest updates correctly, since the issue is not in Telegram connectivity.
Updates are successfully written into channel_ingress_events but processing never advances past the stuck claimed event.

As a consequence:

• new messages are accepted
• updates accumulate
• the bot appears offline
• users receive no responses

Additional information

Recovery procedure

The only successful recovery I've found was:

Stop the gateway.
Backup the SQLite database.
Manually change stuck Telegram records from claimed to failed (or remove the backlog).
Restart the gateway.
Send /new in Telegram to force creation of a new conversation session.

After doing this, Telegram immediately started responding again.

Example SQL used for recovery:

UPDATE channel_ingress_events
SET status='failed',
claim_owner=NULL,
claim_token=NULL,
claimed_at=NULL
WHERE queue_name='["telegram","default"]'
AND status IN ('pending','claimed');

Additional observations

During investigation I've also observed:

Telegram updates being replayed from old conversations (need to manually stop it)
Partial responses being sent before processing stalled.
Session state surviving multiple gateway restarts.
/new creating a fresh session that immediately restored normal behaviour.

This suggests there may be an interaction between:

Telegram ingress queue state
Session restoration
Gateway restart recovery

where a claimed event is never released after an interrupted execution.

A startup recovery routine could automatically:

• detect stale claimed Telegram events;
• release or fail them after a timeout;
• prevent a single event from blocking the entire queue indefinitely.

This would make Telegram much more resilient to crashes and unexpected gateway restarts.

You can find more infos on my solution here: https://matteomorreale.it/usare-le-intelligenze-artificiali/openclaw-non-risponde-su-telegram-dopo-un-riavvio-193042