Summary:

Two related issues with the Telegram channel:

Duplicate message delivery after gateway restart via SIGUSR1
No auto-recovery when Telegram channel exits due to getUpdates timeout
Environment
OpenClaw version: 2026.2.1 (ed4529e)
Node.js: v22.22.0
OS: macOS (Darwin 25.2.0 arm64)
Telegram transport: grammY long-polling
Issue 1: Duplicate Message Delivery
Description
After a gateway restart (via config.apply which sends SIGUSR1), Telegram messages are delivered twice to the agent with the same message_id.

Steps to Reproduce
Have Telegram channel running normally
Trigger a config change that causes gateway restart (SIGUSR1)
Send a message via Telegram
Observe the message arriving twice with identical message_id
Expected Behavior
Each Telegram message should be delivered exactly once, deduplicated by message_id.

Actual Behavior
Messages arrive twice. The inbound dedupe cache (documented in concepts/messages.md) appears to either:

Be cleared on provider restart
Have too short a TTL
Not be checked before the message is enqueued
Relevant Log Pattern
2026-02-03T15:10:53.840Z [gateway] signal SIGUSR1 received
2026-02-03T15:10:53.841Z [gateway] received SIGUSR1; restarting
2026-02-03T15:10:54.480Z [telegram] [default] starting provider (@botName)
2026-02-03T15:10:55.312Z [gateway] signal SIGUSR1 received <-- Second SIGUSR1 within 1 second
2026-02-03T15:10:55.314Z [gateway] received SIGUSR1; restarting
2026-02-03T15:10:55.669Z [telegram] [default] starting provider (@botName)
The Telegram provider restarted twice within ~1 second. Messages sent shortly after were delivered twice.

Issue 2: No Auto-Recovery After Channel Exit
Description
When the Telegram channel exits due to a getUpdates timeout, it does not automatically restart. The channel remains dead until a manual gateway restart.

Steps to Reproduce
Have Telegram channel running with long-polling
Wait for a getUpdates timeout (500 seconds default)
Observe channel exit in logs
Note that channel does not restart automatically
Expected Behavior
When the Telegram channel exits (for any reason), it should automatically attempt to restart with backoff.

Actual Behavior
Channel exits and stays dead. In this case, the channel was down for ~6 hours until a manual config.apply restarted the gateway.

Timeline from Logs
2026-02-03T08:56:30.732Z [telegram] [default] starting provider (@botName) <-- Last successful start
2026-02-03T09:16:40.598Z [telegram] [default] channel exited: Request to 'getUpdates' timed out after 500 seconds
<-- No restart attempts for ~6 hours -->
2026-02-03T15:10:54.480Z [telegram] [default] starting provider (@botName) <-- Manual restart via config.apply
Contributing Factor
During the outage period, there were also repeated FailoverError: No API key found for provider "xai" errors (a misconfigured model fallback). This may have contributed to system instability, though the channel should still auto-recover regardless.

Sanitized Logs
gateway.log (relevant sections)

Frequent restarts before the crash (many config changes during setup)

2026-02-03T08:15:07.699Z [telegram] [default] starting provider (@botName)
2026-02-03T08:28:40.584Z [telegram] [default] starting provider (@botName)
2026-02-03T08:28:49.417Z [telegram] [default] starting provider (@botName)
2026-02-03T08:29:14.952Z [telegram] [default] starting provider (@botName)
2026-02-03T08:31:47.599Z [telegram] [default] starting provider (@botName)
2026-02-03T08:37:28.024Z [telegram] [default] starting provider (@botName)
2026-02-03T08:45:24.938Z [telegram] [default] starting provider (@botName)
2026-02-03T08:47:40.517Z [telegram] [default] starting provider (@botName)
2026-02-03T08:55:05.487Z [telegram] [default] starting provider (@botName)
2026-02-03T08:55:06.672Z [telegram] [default] starting provider (@botName) # <-- 1 second apart
2026-02-03T08:56:29.236Z [telegram] [default] starting provider (@botName)
2026-02-03T08:56:30.732Z [telegram] [default] starting provider (@botName) # <-- 1 second apart, last before crash

6+ hour gap - no telegram activity

2026-02-03T15:10:54.480Z [telegram] [default] starting provider (@botName) # Manual restart
2026-02-03T15:10:55.669Z [telegram] [default] starting provider (@botName) # <-- 1 second apart (duplicates started here)
2026-02-03T15:31:18.037Z [telegram] [default] starting provider (@botName)
gateway.err.log (relevant sections)

xAI errors (misconfigured fallback model without API key)

2026-02-03T08:49:31.665Z [diagnostic] lane task error: lane=main durationMs=2 error="FailoverError: No API key found for provider "xai"..."
2026-02-03T08:54:40.836Z [diagnostic] lane task error: lane=main durationMs=1 error="FailoverError: No API key found for provider "xai"..."
2026-02-03T08:55:09.685Z [diagnostic] lane task error: lane=main durationMs=1 error="FailoverError: No API key found for provider "xai"..."
2026-02-03T08:55:32.483Z [diagnostic] lane task error: lane=main durationMs=1 error="FailoverError: No API key found for provider "xai"..."
2026-02-03T08:56:33.870Z [diagnostic] lane task error: lane=main durationMs=1 error="FailoverError: No API key found for provider "xai"..."

THE CRASH - Telegram channel exits and never recovers

2026-02-03T09:16:40.598Z [telegram] [default] channel exited: Request to 'getUpdates' timed out after 500 seconds
2026-02-03T09:16:40.600Z [openclaw] Suppressed AbortError: AbortError: This operation was aborted

xAI errors continue during outage (heartbeats still running)

2026-02-03T10:08:05.653Z [diagnostic] lane task error: lane=main durationMs=1 error="FailoverError: No API key found for provider "xai"..."
2026-02-03T11:14:31.665Z [diagnostic] lane task error: lane=main durationMs=1 error="FailoverError: No API key found for provider "xai"..."
Suggested Fixes
For Issue 1 (Duplicates)
Persist the dedupe cache across provider restarts (or use a longer TTL)
Alternatively, track lastUpdateId more carefully and ensure updates aren't re-fetched after restart
Consider debouncing rapid SIGUSR1 signals to avoid double-restart scenarios
For Issue 2 (No Auto-Recovery)
Add auto-restart logic when the Telegram channel exits
Implement exponential backoff for restart attempts
Log a warning when channel has been down for extended periods
Consider a health check that detects dead channels and restarts them
Configuration (sanitized)
{
channels: {
telegram: {
enabled: true,
botToken: "",
dmPolicy: "pairing",
groupPolicy: "allowlist",
streamMode: "partial"
}
}
}
No custom timeout or retry settings were configured.