Issue Station
Sign In
Tools hereToolbox

openclaw - 💡(How to fix) Fix [Bug] Telegram deleteWebhook fails on startup: ENETUNREACH despite working curl [2 comments, 3 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#73255•Fetched 2026-04-29 06:21:45
View on GitHub
Comments
2
Participants
3
Timeline
6
Reactions
0
Author
ttomiczekttomiczek
Participants
sktbrdsktbrdsteipetesteipetettomiczekttomiczek
Timeline (top)
cross-referenced ×3commented ×2closed ×1

Fix Action

Fix / Workaround

  1. Start openclaw-gateway with Telegram channel configured (4 accounts)

  2. Observe that deleteWebhook fails for all accounts

  3. After ~20 seconds of retries, the sticky IPv4 dispatcher eventually kicks in

  4. Health endpoint responds, but startup is severely delayed

  5. Gateway starts, all 4 Telegram accounts begin starting provider

  6. Each account immediately fails deleteWebhook with "Network request for 'deleteWebhook' failed!"

  7. The sticky IPv4-only dispatcher kicks in after multiple failures (ENETUNREACH, ETIMEDOUT)

  8. Gateway becomes responsive only after ~20 seconds

  9. The same curl https://api.telegram.org/botXXX/getMe from the host shell works instantly

[telegram] fetch fallback: enabling sticky IPv4-only dispatcher (codes=ETIMEDOUT,ENETUNREACH)
telegram deleteWebhook failed: Network request for 'deleteWebhook' failed!
Telegram webhook cleanup failed: Network request for 'deleteWebhook' failed!; retrying in 2.43s.

Code Example

[telegram] fetch fallback: enabling sticky IPv4-only dispatcher (codes=ETIMEDOUT,ENETUNREACH)
telegram deleteWebhook failed: Network request for 'deleteWebhook' failed!
Telegram webhook cleanup failed: Network request for 'deleteWebhook' failed!; retrying in 2.43s.
RAW_BUFFERClick to expand / collapse

Bug Description

Telegram polling provider fails on every startup with "deleteWebhook failed: Network request for 'deleteWebhook' failed!" followed by retry loops. The network errors show ETIMEDOUT and ENETUNREACH codes, but curl from the same host reaches api.telegram.org fine.

Steps to Reproduce

  1. Start openclaw-gateway with Telegram channel configured (4 accounts)
  2. Observe that deleteWebhook fails for all accounts
  3. After ~20 seconds of retries, the sticky IPv4 dispatcher eventually kicks in
  4. Health endpoint responds, but startup is severely delayed

Environment

  • OpenClaw version: 2026.4.26 (be8c246)
  • Node.js: 22.22.2
  • OS: Linux (VPS)
  • IPv6: enabled on host
  • No proxy environment variables set

Expected Behavior

Telegram polling starts without 20+ second delay on every startup.

Actual Behavior

  1. Gateway starts, all 4 Telegram accounts begin starting provider
  2. Each account immediately fails deleteWebhook with "Network request for 'deleteWebhook' failed!"
  3. The sticky IPv4-only dispatcher kicks in after multiple failures (ENETUNREACH, ETIMEDOUT)
  4. Gateway becomes responsive only after ~20 seconds
  5. The same curl https://api.telegram.org/botXXX/getMe from the host shell works instantly

Relevant Log Excerpt

[telegram] fetch fallback: enabling sticky IPv4-only dispatcher (codes=ETIMEDOUT,ENETUNREACH)
telegram deleteWebhook failed: Network request for 'deleteWebhook' failed!
Telegram webhook cleanup failed: Network request for 'deleteWebhook' failed!; retrying in 2.43s.

Additional Context

  • Direct curl to api.telegram.org works from host shell
  • net.Socket to 149.154.166.110:443 from Node.js works
  • No proxy environment variables
  • Same behavior with IPv6 disabled on host
  • Related open issues: #55387, #47674

extent analysis

TL;DR

The issue can be mitigated by configuring the Node.js application to use IPv4 only for the Telegram API requests.

Guidance

  • Investigate the difference in behavior between curl and Node.js requests to api.telegram.org, focusing on IPv6 vs. IPv4 connectivity.
  • Consider setting the family option to 4 when creating the net.Socket or https request in Node.js to force IPv4 usage.
  • Review related issues #55387 and #47674 for potential insights into similar problems and their solutions.
  • Verify that the sticky IPv4-only dispatcher is correctly handling the fallback to IPv4 after the initial failures.

Example

const https = require('https');

// Force IPv4 usage
const options = {
  family: 4,
  hostname: 'api.telegram.org',
  port: 443,
  path: '/botXXX/getMe',
};

https.get(options, (res) => {
  console.log(`statusCode: ${res.statusCode}`);
}).on('error', (error) => {
  console.error(error);
});

Notes

The provided solution is a workaround and may not address the underlying issue. Further investigation into the differences between curl and Node.js behavior is necessary for a permanent fix.

Recommendation

Apply workaround: Configure Node.js to use IPv4 only for Telegram API requests, as shown in the example, to mitigate the startup delay issue.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#api#tool integration#LLM response#prompt template#environment variable

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING