Skip to content

[Bug]: [Telegram] sendChatAction and sendMessage fail with "Network request failed" — polling works, direct grammy/undici calls succeed #76172

@nathanrhoffman-cmd

Description

@nathanrhoffman-cmd

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

The Telegram channel fails to send any outbound messages. Both sendChatAction and sendMessage consistently fail with:

Network request for 'sendChatAction' failed!
Network request for 'sendChatAction' failed!
The gateway receives inbound messages and Claude processes them (attempt-dispatch and stream-ready complete), but the response cannot be delivered back to Telegram.

This issue reproduces on both native Windows npm install and Docker container. It is not a network/connectivity issue — see diagnostics below.

Works:

Direct Node.js fetch() (native) → sendMessage → OK 200 ✓
Direct undici fetch → sendMessage → OK 200 ✓
Direct grammy bot.api.sendMessage() → received in Telegram ✓
TCP reachability test: api.telegram.org:443 → TcpTestSucceeded: True ✓
Inbound polling: messages received by OpenClaw ✓
Agent processing: Claude generates responses (stream-ready completes) ✓

Fails:

OpenClaw's internal sendChatAction → Network request failed ✗
OpenClaw's internal sendMessage (reply delivery) → Network request failed ✗
Polling long-poll (getUpdates) → fetch-timeout after ~30s ✗

Steps to reproduce

Run OpenClaw 2026.4.29 on Windows (npm) or Docker on Windows host
Configure Telegram channel with valid bot token
Start gateway — observe starting provider (@botName) in logs
Send a DM to the bot
Observe: agent dispatches and processes, but no reply arrives in Telegram
Logs show sendChatAction failed and sendMessage failed

Expected behavior

When a user sends a DM to the bot, OpenClaw delivers the agent's response back to Telegram via sendMessage. The typing indicator (sendChatAction) shows while the agent is processing.

Actual behavior

Both sendChatAction and sendMessage fail with "Network request failed". The agent receives and processes the message (Claude generates a response) but the reply is never delivered. The Telegram polling (getUpdates) also stalls and times out after ~30 seconds, requiring a transport rebuild loop.

OpenClaw version

2026.4.29 (a448042)

Operating system

Windows 10.0.26200 (x64) / Docker Linux container

Install method

npm (Windows) + Docker (ghcr.io/openclaw/openclaw:latest)

Model

anthropic/claude-sonnet-4-5

Provider / routing chain

Telegram (long polling) → OpenClaw gateway → anthropic/claude-sonnet-4-5 → reply fails at sendMessage (Telegram outbound)

Additional provider/model setup details

Provider: Anthropic (API key auth)
Model: anthropic/claude-sonnet-4-5
Auth method: ANTHROPIC_API_KEY environment variable
Agent processes requests successfully — auth and model resolution complete without errors. Issue is isolated to Telegram outbound send path, not provider connectivity

Logs, screenshots, and evidence

[telegram] [default] starting provider (@K_Rock_Bot)
[fetch-timeout] fetch timeout reached; aborting operation
[telegram] sendChatAction failed: Network request for 'sendChatAction' failed!
[agent/embedded] attempt-dispatch totalMs=35670 ... auth:4258ms ... attempt-dispatch:5164ms
[agent/embedded] stream-ready totalMs=42424 ...
[fetch-timeout] fetch timeout reached; aborting operation
[telegram] sendMessage failed: Network request for 'sendMessage' failed!
[telegram] final reply failed: HttpError: Network request for 'sendMessage' failed!
[telegram] Polling stall detected (no completed getUpdates for 201.36s)

Impact and severity

Impact: Complete loss of Telegram channel functionality — bot receives messages and Claude processes them but no responses are ever delivered. Channel is unusable.
Severity: High — affects all outbound Telegram sends on Windows (both native npm and Docker). Workaround exists via browser dashboard only.

Additional information

Config

channels.telegram.network.autoSelectFamily: false
OPENCLAW_TELEGRAM_DISABLE_AUTO_SELECT_FAMILY=1
OPENCLAW_TELEGRAM_DNS_RESULT_ORDER=ipv4first

(None of the above resolved the issue)

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workingbug:behaviorIncorrect behavior without a crash

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions