🆘 Telegram polling stops silently after startup (Hostinger Docker)

[fleet arch]

Two things in your report jump out (and one of them is a gotcha):

1) “Silence after startup” is normal for Telegram polling

Telegram long-polling doesn’t print a “Listening…” style log line. After:

• [telegram] starting provider …
• telegram: autoSelectFamily=false (default-node22)

…it can be happily blocking inside getUpdates with no further logs until an error happens.

So the lack of logs doesn’t prove it’s not polling.

Docs: https://docs.openclaw.ai/channels/telegram

2) getUpdates => [] does not prove OpenClaw isn’t polling

If OpenClaw is polling, it may consume updates before your manual getUpdates sees them.

If you want to use getUpdates as a conflict test, call it with a timeout (so it behaves like long polling). While OpenClaw is running, this should often produce a 409:

curl "https://api.telegram.org/bot<token>/getUpdates?timeout=30"

(Calling it with the default timeout often isn’t a great “is another poller running?” check.)

3) Hostinger VPS + Node 22: this looks like an IPv6/Happy-Eyeballs edge case

That autoSelectFamily=false (default-node22) line is OpenClaw applying a Node 22 workaround. On some VPS networks with flaky IPv6, disabling auto family selection can cause Node’s fetch/undici to “stick” on a bad address family (curl works because it does its own happy-eyeballs behavior).

Try overriding it for Telegram:

Option A (config)

{

  channels: {
    telegram: {
      network: {
        autoSelectFamily: true,
      },
    },
  },
}

Option B (env var)

Set this in your Docker env and restart:

• OPENCLAW_TELEGRAM_ENABLE_AUTO_SELECT_FAMILY=1

(These are real supported knobs; see the Telegram docs config reference.)
Docs: https://docs.openclaw.ai/channels/telegram#telegram-config-reference-pointers

Quick “prove where it’s failing” checklist

Run these on the gateway host/container right after DMing the bot:

openclaw channels status --probe
openclaw channels logs --channel telegram

Docs: https://docs.openclaw.ai/channels/troubleshooting

If you paste the output of openclaw channels status --probe + the Telegram log tail around a test DM, it’ll usually make the failure mode obvious (polling vs auth vs send failures vs network).

If this fixes it, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow indexes it.

[sage sedge]

Update: autoSelectFamily=true fixed polling, but bot still doesn't respond

Thanks for the suggestion! I applied the env var fix:

OPENCLAW_TELEGRAM_ENABLE_AUTO_SELECT_FAMILY=1
Results after the fix:

✅ autoSelectFamily=true (env:OPENCLAW_TELEGRAM_ENABLE_AUTO_SELECT_FAMILY) — confirmed in logs
✅ openclaw channels status --probe → Telegram default: enabled, configured, running, mode:polling, bot:@DroneTristan_bot, token:config, works
✅ getUpdates?timeout=30 → returns 409 Conflict (confirms OpenClaw IS polling)
✅ Dashboard Chat works perfectly (AI model responds)
But still no response in Telegram. When I DM the bot:

Zero log entries about receiving any message
openclaw channels logs --channel telegram shows only the startup line
openclaw pairing list telegram → "No pending telegram pairing requests"
Log file (tail -10) shows only heartbeat entries, no inbound activity
Current config (verified inside container):

json
"channels": {
"telegram": {
"enabled": true,
"botToken": "<set>",
"dmPolicy": "open",
"allowFrom": ["*"]
}
}
What I've tried:

deleteWebhook?drop_pending_updates=true + restart
Created a brand new bot via BotFather
Cleared credentials (rm telegram-*.json)
Verified getMe returns correct bot info
Multiple docker compose down && up cycles
It feels like OpenClaw is polling successfully but silently discarding all received messages. Any ideas?

[fleet arch]

That “polling works (409), but Telegram DMs do nothing + no pairing requests” pattern is very consistent with one specific thing:

Likely cause: stale Telegram update offset file (especially after switching bots)

OpenClaw persists the last processed update_id in state:

• ~/.openclaw/telegram/update-offset-default.json (default account)
• (or under $OPENCLAW_STATE_DIR/telegram/… if you set a custom state dir)

If you previously ran a different bot token (or created a brand new bot), the new bot’s update_id sequence starts low again. If the stored lastUpdateId is higher, OpenClaw will silently skip every update (no inbound logs unless verbose), while still “polling” successfully.

Fix (safe: move it aside, don’t delete)

Inside the container:

echo "STATE=${OPENCLAW_STATE_DIR:-$HOME/.openclaw}"
ls -la "${OPENCLAW_STATE_DIR:-$HOME/.openclaw}/telegram" || true

cat  "${OPENCLAW_STATE_DIR:-$HOME/.openclaw}/telegram/update-offset-default.json" || true

mv "${OPENCLAW_STATE_DIR:-$HOME/.openclaw}/telegram/update-offset-default.json" \
   "${OPENCLAW_STATE_DIR:-$HOME/.openclaw}/telegram/update-offset-default.json.bak.$(date +%s)"

openclaw gateway restart

Then DM the bot again.

If it still doesn’t reply, 2 quick confirmations

1. Stop OpenClaw, then send a DM, then run:

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

You should see your DM in the result. If you don’t, it’s Telegram-side (wrong bot/chat, privacy settings don’t affect DMs, but wrong token/target does).

2. Start the gateway in foreground with verbose (temporarily) to see raw updates / skips:

openclaw gateway run --verbose

If the offset file was the issue, this usually fixes it immediately. If it does, please mark the solution (Apps → ✅ Mark Solution) so it’s indexed.

[sage sedge]

How can I mark this as solved the problem? I'm looking everywhere on Discord PTB