#telegram errors

1 messages · Page 1 of 1 (latest)

stiff perch
#

sometimes whenever i send a telegram message to my agent i see the following errors:

03:10:09 error gateway/channels/telegram {"subsystem":"gateway/channels/telegram"} telegram sendMessage failed: Network request for 'sendMessage' failed!
03:10:09 error gateway/channels/telegram {"subsystem":"gateway/channels/telegram"} telegram final reply failed: HttpError: Network request for 'sendMessage' failed!
03:10:20 warn [openclaw] Non-fatal unhandled rejection (continuing): TypeError: fetch failed
at node:internal/deps/undici/undici:14902:13
at processTicksAndRejections (node:internal/process/task_queues:105:5)
03:10:20 error telegram/api {"subsystem":"telegram/api"} telegram sendChatAction failed: Network request for 'sendChatAction' failed!

however it doesnt seem to be happening all the time

dense perchBOT
#

Those logs basically mean “the Gateway couldn’t reach Telegram’s Bot API over HTTPS for a moment” (Node’s fetch/undici throws, and grammY surfaces it as Network request for 'sendMessage' failed). The sendChatAction one is just the typing indicator failing; the sendMessage one is the real delivery failure.

Because it’s intermittent, the usual culprits are:

  • Flaky outbound network on the gateway host (Wi‑Fi, VPS packet loss, transient DNS issues).
  • IPv6 weirdness: some hosts resolve api.telegram.org to IPv6 first; if your IPv6 egress is broken/partial you’ll get “works sometimes” behavior.
  • Blocked Telegram on that network/region (then you’d typically need a proxy).

Quick things to try / check

  1. Grab versions + context (this matters for known Node network behavior):
  • openclaw --version
  • node --version
  • where the gateway runs (home machine / VPS / docker / corporate network)
  1. Check DNS answers (IPv4 vs IPv6) (from the gateway host):
# 
dig +short api.telegram.org A
dig +short api.telegram.org AAAA

If you get AAAA records and your IPv6 is flaky, fix IPv6 egress or force a more IPv4-friendly behavior.

  1. If you suspect IPv6 issues: try toggling Telegram’s autoSelectFamily setting in config:
{
  channels: {
    telegram: {
      network: { autoSelectFamily: true } // try this if IPv6 is flaky
    }
  }
}

Docs section that mentions this exact failure mode: https://docs.openclaw.ai/channels/telegram#polling-or-network-instability

#
  1. Make it more resilient to brief outages: enable/raise Telegram retry (so a 1–2s blip doesn’t drop replies):
{
  channels: {
    telegram: {
      retry: { attempts: 3, minDelayMs: 400, maxDelayMs: 30000, jitter: 0.1 }
    }
  }
}
  1. If Telegram is blocked where the gateway runs: configure a proxy:

If you paste one “full” error instance

If you can paste a slightly longer log chunk around the failure (sometimes the underlying cause is ECONNRESET / ENOTFOUND / ETIMEDOUT), we can usually tell immediately whether it’s DNS, IPv6, or just transient connectivity.

stiff perch
#

openclaw version 2026.2.14
node version 22.22.0

root@srv1383751:~# dig +short api.telegram.org A
149.154.166.110
root@srv1383751:~# dig +short api.telegram.org AAAA
2001:67c:4e8:f004::9

dense perchBOT
#

You’ve got both IPv4 and IPv6 DNS answers:

  • A: 149.154.166.110
  • AAAA: 2001:67c:4e8:f004::9

Intermittent fetch failed + “Network request … failed” on VPSes is very often “IPv6 exists on paper but is flaky in practice”, so some requests succeed (IPv4) and some hit a bad/slow IPv6 path.

1) First: confirm what OpenClaw decided for autoSelectFamily

On Node 22+, OpenClaw defaults to disabling autoSelectFamily for Telegram (Node Happy Eyeballs timeout workaround), and it logs it once.

Please grep your logs for this line:

  • telegram: autoSelectFamily=...

If you don’t see it, or it says true, then something (config/env) is overriding.

Relevant overrides:

  • config: channels.telegram.network.autoSelectFamily
#
  • env: OPENCLAW_TELEGRAM_ENABLE_AUTO_SELECT_FAMILY=1 / OPENCLAW_TELEGRAM_DISABLE_AUTO_SELECT_FAMILY=1

2) Quick connectivity test: does IPv6 actually work reliably?

Run these from the gateway host (token can be any bot token you already have configured):

curl -4 -sS "https://api.telegram.org/bot<token>/getMe" | head
curl -6 -sS "https://api.telegram.org/bot<token>/getMe" | head
  • If -4 is consistently fine and -6 fails/hangs sometimes → fix is “prefer/force IPv4” (or properly fix IPv6 egress).
  • If both fail sometimes → it’s more general network/DNS/egress instability.

3) Practical mitigations (pick one)

A) Force the OpenClaw-side setting explicitly (even if it’s the default, make it unambiguous):

# 
{
  channels: {
    telegram: {
      network: { autoSelectFamily: false },
      // optional resilience:
      retry: { attempts: 3, minDelayMs: 400, maxDelayMs: 30000, jitter: 0.1 },
    },
  },
}

B) Force IPv4 preference at the Node level (service env), if you control how the gateway daemon is launched:

  • NODE_OPTIONS=--dns-result-order=ipv4first

C) If Telegram is blocked / unreliable from that DC/region: set a proxy:

  • channels.telegram.proxy: "socks5://..." (or http proxy)