Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix [telegram] noisy IPv4 fallback warning ignores --dns-result-order=ipv4first [1 pull requests, 3 comments, 4 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#75904•Fetched 2026-05-03 04:44:27
View on GitHub
Comments
3
Participants
4
Timeline
5
Reactions
2
Author
highfly-hihighfly-hi
Participants
clawsweeper[bot]clawsweeper[bot]highfly-hihighfly-hineeravmakwananeeravmakwanasteipetesteipete
Timeline (top)
commented ×3closed ×1cross-referenced ×1

Error Message

  • Correlates with brief network reachability blips; the plugin's own retry already recovers, so the message could be debug instead of warn.

Fix Action

Fix / Workaround

Workaround applied locally

  • NODE_OPTIONS=--dns-result-order=ipv4first in gateway.systemd.env (helps other plugins; telegram noise persists).
  • No effective workaround within configuration today.

PR fix notes

PR #75913: fix(telegram): log IPv4 transport fallback at debug (#75904)

Description (problem / solution / changelog)

Summary

  • AI-assisted (implementation and validation run in this environment)

Root cause: When Telegram Bot API calls hit dual-stack connect failures, resolveTelegramTransport promotes the undici dispatcher to the IPv4-only sticky fallback. That transition was logged at warn, so brief IPv6/route blips produced high-volume journal noise even though the next fetch attempt succeeded immediately.

Fix: Log the same diagnostic line (including error codes and optional reason=) at debug instead of warn. Env-proxy dispatcher init failures and other unrelated log.warn paths are unchanged.

Linked issue: Fixes #75904.

Why this is safe: No change to fallback predicates, dispatcher selection, retries, or timeouts—only the log level for the sticky promotion message. Operators who need the signal can enable debug for subsystem telegram/network (or broader debug) per existing logging controls.

Security / runtime controls (unchanged): Same HTTPS targets, proxy handling, SSRF guards, pinned-IP fallback policy, and transport close() lifecycle as before. No prompt or config semantics changed.

Tests run:

  • git diff --check
  • pnpm vitest run extensions/telegram/src/fetch.test.ts
  • pnpm check:changed — failed in this checkout on pre-existing extensions/xai oxlint issues (no-useless-fallback-in-spread); not introduced by this branch (only CHANGELOG.md and extensions/telegram/src/fetch*.ts touched).

Out of scope (follow-ups):

  • Reading dns.getDefaultResultOrder() to mirror NODE_OPTIONS=--dns-result-order=ipv4first when OpenClaw has no explicit Telegram DNS setting.
  • Rate-limiting or coalescing multiple fallback promotions per account/window.

Changed files

  • CHANGELOG.md (modified, +1/-0)
  • extensions/telegram/src/fetch.test.ts (modified, +23/-2)
  • extensions/telegram/src/fetch.ts (modified, +9/-1)

Code Example

[telegram] connection retry: switching to IPv4 fallback
RAW_BUFFERClick to expand / collapse

[telegram] noisy IPv4 fallback log spam (~128 events / 24 h) despite functional polling

Environment

  • openclaw 2026.4.29
  • Telegram channel plugin (built-in), 5 accounts polling via long-poll
  • Host NODE_OPTIONS=--dns-result-order=ipv4first (set in gateway.systemd.env)
  • Linux 6.17, dual-stack network (IPv6 SLAAC sometimes unstable)

Symptom

With IPv4-first DNS already enforced at the Node level, the Telegram plugin still logs:

[telegram] connection retry: switching to IPv4 fallback

128 occurrences in the last 24h across 5 accounts (not blocking, polling continues immediately). Distribution: ~25 events/account/day, mostly in 1-3 minute clusters.

Why it matters

  • High signal-to-noise during operational triage — this warning fires more often than any other in the gateway.
  • Suggests the plugin maintains its own dual-stack resolver / agent that does not honor --dns-result-order=ipv4first.
  • Correlates with brief network reachability blips; the plugin's own retry already recovers, so the message could be debug instead of warn.

Proposed fix

  • Honor process-level dns.setDefaultResultOrder() in the telegram HTTPS agent: read process.options || dns.getDefaultResultOrder?.() at agent construction and skip IPv6 attempts when ipv4first.
  • Or expose channels.telegram.transport: { family: 4 | 6 | 0 } so operators can pin the family without fighting Node defaults.
  • Downgrade the recovery message to debug when the first attempt within a window already succeeded after fallback.

Workaround applied locally

  • NODE_OPTIONS=--dns-result-order=ipv4first in gateway.systemd.env (helps other plugins; telegram noise persists).
  • No effective workaround within configuration today.

Repro

  1. Run the gateway on a dual-stack host where IPv6 is available but lossy.
  2. Configure ≥1 Telegram account in channels.telegram.accounts.
  3. After 24 h, count: journalctl --user -u openclaw-<profile>-gateway.service --since "24 hours ago" | grep -c "switching to IPv4 fallback".

extent analysis

TL;DR

The Telegram plugin's noisy IPv4 fallback log spam can be mitigated by modifying the plugin to honor the process-level DNS result order or by exposing a configuration option to pin the IP family.

Guidance

  • Investigate the proposed fix to honor dns.setDefaultResultOrder() in the Telegram HTTPS agent, which may require changes to the plugin's code.
  • Consider exposing a configuration option channels.telegram.transport: { family: 4 | 6 | 0 } to allow operators to pin the IP family.
  • Downgrade the recovery message to debug when the first attempt within a window already succeeded after fallback to reduce log noise.
  • Verify the effectiveness of any changes by running the repro steps and checking the log output.

Example

No code snippet is provided as the issue does not contain sufficient information to create a specific example.

Notes

The issue is specific to the Telegram plugin and its interaction with the Node.js DNS result order. Any changes or workarounds may need to be applied to the plugin's code or configuration.

Recommendation

Apply a workaround by modifying the Telegram plugin to honor the process-level DNS result order, as this is the most direct way to address the 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 middleware#SSR setup#ISR setup#authentication setup#request error

Still need to ship something?

×6

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

Back to top recommendations

TRENDING