Summary

Telegram direct-message inbound processing wedged while the OpenClaw gateway process stayed alive enough for status/delivery bookkeeping. Manual openclaw gateway restart killed one stale gateway process and immediately restored Telegram inbound handling.

Environment

• OpenClaw: 2026.5.12 (f066dd2)
• Install path: /opt/homebrew/bin/openclaw
• Platform: macOS LaunchAgent gateway
• Telegram mode: polling
• Bot provider: Telegram channel plugin

Timeline, America/New_York

• 2026-05-15 09:48:13: gateway log shows [telegram:default] health-monitor: restarting (reason: stale-socket)
• 2026-05-15 09:48:28: [telegram] [default] auto-restart attempt 1/10 in 5s
• 2026-05-15 09:48:34: [telegram] [default] starting provider (...)
• 2026-05-15 10:00:23: channels.status returned ok in ~324ms
• 2026-05-15 10:00:00-10:02:41: an isolated cron job checked Telegram/group state and reported gateway/Telegram connected; cron delivery bookkeeping later reported delivered
• 2026-05-15 10:02:13: gateway log shows cron: job created
• 2026-05-15 10:11-10:13: multiple Telegram direct messages were sent by the user, but no corresponding inbound entries appear in the gateway log
• 2026-05-15 10:13:58: user ran openclaw gateway restart; output: killing 1 stale gateway process(es) before restart: 25576
• 2026-05-15 10:14:14: gateway ready and Telegram provider started
• 2026-05-15 10:14:15: first pending Telegram direct message appeared in gateway log immediately after restart

Observed Behavior

• Gateway HTTP health could be ok while Telegram inbound polling/processing was not functioning.
• A cron-delivery record marked Telegram delivery as delivered / deliveryStatus: delivered / fallbackUsed: true shortly before the wedge was noticed.
• The user’s Telegram messages did not appear in gateway logs until after a full gateway restart.
• Manual restart killed a stale gateway process and restored inbound handling immediately.

Expected Behavior

• Telegram stale-socket recovery should either fully restore inbound polling or escalate to a full gateway/channel restart when polling does not resume.
• Health/status checks should detect a live-but-wedged Telegram provider, not just gateway HTTP liveness.
• Delivery bookkeeping should not imply end-to-end Telegram reliability if the channel/gateway path is wedged.

Local Mitigation

Added an external LaunchAgent watchdog that runs every 60s and checks:

• http://127.0.0.1:18789/health
• openclaw channels status --probe with a 15s timeout
• gateway log events for stale-socket / auto-restart / gateway restart

On probe failure or timeout it kicks ai.openclaw.gateway via launchctl kickstart -k and sends a direct Telegram Bot API alert outside the normal OpenClaw message path.

Request

Please investigate the Telegram provider stale-socket recovery path and channel health probe semantics. The problematic state appears to be: gateway process alive, HTTP/status partially green, Telegram provider previously restarted for stale socket, but inbound polling stopped until a full gateway restart.