openclaw - 💡(How to fix) Fix [Bug] 2026.4.27 regression: Telegram provider logs "starting" but never begins long-poll; inbound silently dropped, outbound still works (regression of #45714 / #69064) [3 comments, 2 participants]

Summary

On openclaw 2026.4.27 (cbc2ba0), macOS 15 (Darwin 25.4.0), the Telegram provider logs [default] starting provider (@ACP_openclaw_bot) at startup and then never produces any further telegram-subsystem activity. No getUpdates, no inbound message events, no error. Outbound sendMessage still works for any send the agent kicks off WITHOUT requiring inbound (e.g., scheduled posts, replies to messages received before the stall). This matches the symptom of #45714 and the silent-no-resume failure mode of #69064, both closed in the prior week.

Environment

• openclaw 2026.4.27 (cbc2ba0), installed via global npm
• macOS 15 (Darwin 25.4.0), Apple Silicon (Mac mini)
• Node 25.8.0
• Service via launchd (ai.openclaw.gateway)
• ~20 agents, multiple Telegram supergroups, two of which use forum topics

Repro

1. Have a healthy gateway running with active Telegram polling.
2. Wait for any transient network blip that causes openclaw's telegram/network layer to log fetch fallback: enabling sticky IPv4-only dispatcher (codes=ETIMEDOUT,EHOSTUNREACH).
3. Restart the gateway (launchctl kickstart -k).
4. Observe: at startup the IPv4-only fallback fires immediately (within ~12ms of provider start), the provider logs [default] starting provider (@ACP_openclaw_bot), and then no further telegram-subsystem activity occurs. Inbound messages sent to any group never reach the gateway.

Evidence (last telegram-subsystem lines after each of two restarts)

First restart 16:34:55 EDT:

16:34:54.982  WARN  telegram/network            fetch fallback: enabling sticky IPv4-only dispatcher (codes=ETIMEDOUT,EHOSTUNREACH)
16:34:55.664  INFO  gateway/channels/telegram   [default] starting provider (@ACP_openclaw_bot)
(no further telegram lines for 14+ minutes)

Second restart 16:55:01 EDT:

16:55:06.694  WARN  telegram/network            fetch fallback: enabling sticky IPv4-only dispatcher (codes=ETIMEDOUT,EHOSTUNREACH)
16:55:07.379  INFO  gateway/channels/telegram   [default] starting provider (@ACP_openclaw_bot)
(no further telegram lines)

Direct connectivity check from the same host at the time of restart:

$ curl -4 --max-time 8 https://api.telegram.org/
302 in 347ms (DNS 4ms, connect 117ms, TLS 243ms, total 347ms)

So the network is healthy; the bot's startup state machine is stuck behind a stale "sticky IPv4-only" decision.

Why this looks like a regression of #45714 / #69064

• #45714 ("provider stops polling while outbound still works"): exact symptom. Outbound to DMs continued to succeed in our log earlier today; group inbound silent.
• #69064 ("auto-recovery sometimes completes silently without resuming polling; requires manual service restart"): we are now in the variant where MANUAL restart also doesn't resume polling, because the persisted IPv4-only-fallback flag re-engages at every startup.

Suggested investigation

1. Whatever persists telegram/network's IPv4-only fallback decision should expire on a TTL or be cleared on a clean SIGTERM. Right now it appears to survive across restarts, pre-empting clean retries.
2. After [default] starting provider, the next expected lifecycle event (deleteWebhook ack / first getUpdates) should ALWAYS be logged at INFO — even on success — so users can tell the difference between "polling started" and "stuck in startup."
3. If the first deleteWebhook/getWebhookInfo call fails with ETIMEDOUT/EHOSTUNREACH, the bot should exit with a clear error so launchd can restart it cleanly, not silently retry without logging.

Workaround used (none worked permanently)

• Two launchctl kickstart -k restarts, ~20 minutes apart, both reproduced the same silent-stuck state.

Happy to attach the full /tmp/openclaw/openclaw-2026-04-30.log if useful (~4MB; I'll redact session content if requested).