fix(telegram): add dnsResultOrder=ipv4first default on Node 22+ to fix fetch failures by Glucksberg · Pull Request #5405 · openclaw/openclaw

Glucksberg · 2026-01-31T12:59:35Z

Summary

Some networks/ISPs have issues with IPv6 causing Telegram API fetch failures, even with autoSelectFamily=false. This adds a complementary fix using dns.setDefaultResultOrder('ipv4first') to prioritize IPv4 addresses in DNS resolution.

Problem

From #5311:

message tool with action=send fails with "Network request for 'sendMessage' failed!"
Normal conversation replies work fine
Manual curl to Telegram API works
autoSelectFamily=false is already applied but not sufficient

Solution

Add dnsResultOrder=ipv4first as default on Node 22+ alongside the existing autoSelectFamily=false:

dns.setDefaultResultOrder('ipv4first');

This matches the workaround suggested in the issue comments:

NODE_OPTIONS='--dns-result-order=ipv4first'

Changes

Add dnsResultOrder config option (ipv4first | verbatim)
Default to ipv4first on Node 22+
Add OPENCLAW_TELEGRAM_DNS_RESULT_ORDER env var override
Log the applied setting for debugging

Configuration

{
  "channels": {
    "telegram": {
      "network": {
        "dnsResultOrder": "ipv4first"
      }
    }
  }
}

Or via environment variable:

OPENCLAW_TELEGRAM_DNS_RESULT_ORDER=ipv4first

Fixes #5311

Greptile Overview

Greptile Summary

This PR adds a Telegram-specific network workaround for Node 22+ by introducing a new channels.telegram.network.dnsResultOrder setting (and env override OPENCLAW_TELEGRAM_DNS_RESULT_ORDER) and applying it via dns.setDefaultResultOrder('ipv4first') alongside the existing autoSelectFamily workaround. Config schema/UI hints and Zod validation were updated accordingly.

Main risk area is the global nature of these Node defaults: the implementation caches “applied” settings and currently marks them applied even if the underlying setter throws, which can prevent later successful application in environments where the setter becomes available.

Confidence Score: 4/5

Generally safe to merge, with one correctness edge case around caching the applied network defaults.
Changes are small and localized, with schema/type updates consistent across config layers. The primary concern is applyTelegramNetworkWorkarounds() updating applied* state before confirming the runtime setter succeeded, which can lock in a no-op if the call throws.
src/telegram/fetch.ts

greptile-apps

_{2 files reviewed, 3 comments}

_{Edit Code Review Agent Settings | Greptile}

greptile-apps · 2026-01-31T13:01:23Z

src/telegram/fetch.ts

+  // Apply DNS result order workaround for IPv4/IPv6 issues.
+  // Some APIs (including Telegram) may fail with IPv6 on certain networks.
+  // See: https://github.com/openclaw/openclaw/issues/5311
+  const dnsDecision = resolveTelegramDnsResultOrderDecision({ network });


[P1] applyTelegramNetworkWorkarounds() now sets appliedDnsResultOrder/appliedAutoSelectFamily before attempting dns.setDefaultResultOrder()/net.setDefaultAutoSelectFamily(). If those setters throw (e.g. unsupported runtime), the cache still updates and prevents future attempts even if a later call runs in an environment where it would succeed.

A safer pattern is to only update applied* after the setter succeeds, or revert in the catch.

Prompt To Fix With AI

This is a comment left during a code review. Path: src/telegram/fetch.ts Line: 33:36 Comment: [P1] `applyTelegramNetworkWorkarounds()` now sets `appliedDnsResultOrder`/`appliedAutoSelectFamily` *before* attempting `dns.setDefaultResultOrder()`/`net.setDefaultAutoSelectFamily()`. If those setters throw (e.g. unsupported runtime), the cache still updates and prevents future attempts even if a later call runs in an environment where it would succeed. A safer pattern is to only update `applied*` after the setter succeeds, or revert in the `catch`. How can I resolve this? If you propose a fix, please make it concise.

greptile-apps · 2026-01-31T13:01:24Z

src/telegram/network-config.ts

+export type TelegramDnsResultOrderDecision = {
+  value: string | null;
+  source?: string;


[P2] TelegramDnsResultOrderDecision.value is typed as string | null, but downstream it’s treated as a strict union ("ipv4first" | "verbatim") and then cast in fetch.ts. Tightening this type to "ipv4first" | "verbatim" | null would remove the need for the cast and prevent accidental future values from compiling.

Also, resolveTelegramDnsResultOrderDecision() already normalizes/filters to those two values, so the narrower type matches current behavior.

Prompt To Fix With AI

This is a comment left during a code review. Path: src/telegram/network-config.ts Line: 16:18 Comment: [P2] `TelegramDnsResultOrderDecision.value` is typed as `string | null`, but downstream it’s treated as a strict union (`"ipv4first" | "verbatim"`) and then cast in `fetch.ts`. Tightening this type to `"ipv4first" | "verbatim" | null` would remove the need for the cast and prevent accidental future values from compiling. Also, `resolveTelegramDnsResultOrderDecision()` already normalizes/filters to those two values, so the narrower type matches current behavior. How can I resolve this? If you propose a fix, please make it concise.

greptile-apps · 2026-01-31T13:01:25Z

src/telegram/network-config.ts

+  // Check config
+  const configValue = (params?.network as { dnsResultOrder?: string } | undefined)?.dnsResultOrder
+    ?.trim()
+    .toLowerCase();


[P3] configValue is extracted via (params?.network as { dnsResultOrder?: string })?.dnsResultOrder?.trim().toLowerCase(). Since TelegramNetworkConfig.dnsResultOrder is already a union of string literals, this cast/normalization is redundant and makes the code harder to follow.

If you want case-insensitive config parsing, it might be better handled at schema/parse time rather than by casting away the type here.

_{Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!}

Prompt To Fix With AI

This is a comment left during a code review. Path: src/telegram/network-config.ts Line: 74:77 Comment: [P3] `configValue` is extracted via `(params?.network as { dnsResultOrder?: string })?.dnsResultOrder?.trim().toLowerCase()`. Since `TelegramNetworkConfig.dnsResultOrder` is already a union of string literals, this cast/normalization is redundant and makes the code harder to follow. If you want case-insensitive config parsing, it might be better handled at schema/parse time rather than by casting away the type here. <sub>Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!</sub> How can I resolve this? If you propose a fix, please make it concise.

vercel · 2026-02-22T10:34:35Z

@Glucksberg is attempting to deploy a commit to the 0xBuns Team on Vercel.

A member of the Team first needs to authorize it.

…x fetch failures Some networks/ISPs have issues with IPv6 causing Telegram API fetch failures, even with autoSelectFamily=false. This adds a complementary fix using dns.setDefaultResultOrder('ipv4first') to prioritize IPv4 addresses in DNS resolution. Changes: - Add dnsResultOrder config option (ipv4first | verbatim) - Default to 'ipv4first' on Node 22+ alongside existing autoSelectFamily=false - Add OPENCLAW_TELEGRAM_DNS_RESULT_ORDER env var override - Log the applied setting for debugging The combination of autoSelectFamily=false and dnsResultOrder=ipv4first addresses the Happy Eyeballs timeout and IPv6 resolution issues that cause 'Network request failed' errors on certain network configurations. Fixes openclaw#5311

) OpenRouter's 'auto' model is stored in the registry with the full id 'openrouter/auto', but parseModelRef splits 'openrouter/auto' into provider='openrouter' and modelId='auto'. The registry lookup then fails because it searches for id='auto' instead of 'openrouter/auto'. This adds a fallback that tries the full id when the initial lookup fails for this specific case.

obviyus · 2026-02-22T14:37:55Z

Merged via squash.

Prepared head SHA: 71366e9
Merge commit: 53adae9

Thanks @Glucksberg!

openclaw-barnacle bot added the channel: telegram Channel integration: telegram label Jan 31, 2026

greptile-apps bot reviewed Jan 31, 2026

View reviewed changes

openclaw-barnacle bot added agents Agent runtime and tooling docs Improvements or additions to documentation and removed docs Improvements or additions to documentation labels Feb 1, 2026

openclaw-barnacle bot added size: S experienced-contributor labels Feb 13, 2026

thewilloftheshadow force-pushed the main branch from bfc1ccb to f92900f Compare February 15, 2026 18:46

Glucksberg and others added 5 commits February 22, 2026 20:07

fix(telegram): apply network defaults only after successful setter calls

0817137

docs: add changelog entry for telegram dns workaround

29fd786

docs: polish changelog attribution for openclaw#5405

71366e9

github-actions bot mentioned this pull request Feb 22, 2026

📡 Upstream Digest — 2026-02-22 16:20 UTC curtismercier/openclaw-mods#101

Open

gemini-code-assist bot mentioned this pull request Feb 23, 2026

Sync with remote: 2/23/2026 ArchitectVS7/OpenClaw#18

Merged

18 tasks

github-actions bot mentioned this pull request Feb 24, 2026

上游更新: v2026.2.23, v2026.2.22 — 114 P0 + 122 P1 待合并 jiulingyun/openclaw-cn#328

Closed

jiulingyun mentioned this pull request Feb 24, 2026

upstream(telegram-part4): 移植 4 个冲突 commit (P1) — v2026.2.21→v2026.2.23 jiulingyun/openclaw-cn#443

Closed

6 tasks

sircrumpet mentioned this pull request Mar 9, 2026

fix(telegram): use sticky IPv4 fallback on dual-stack failures #40435

Closed

19 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

fix(telegram): add dnsResultOrder=ipv4first default on Node 22+ to fix fetch failures#5405

fix(telegram): add dnsResultOrder=ipv4first default on Node 22+ to fix fetch failures#5405
obviyus merged 5 commits intoopenclaw:mainfrom
Glucksberg:fix/telegram-dns-ipv4first

Glucksberg commented Jan 31, 2026 •

edited by greptile-apps bot

Loading

Uh oh!

greptile-apps bot left a comment

Uh oh!

greptile-apps bot Jan 31, 2026

Uh oh!

greptile-apps bot Jan 31, 2026

Uh oh!

greptile-apps bot Jan 31, 2026

Uh oh!

vercel bot commented Feb 22, 2026

Uh oh!

obviyus commented Feb 22, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

Glucksberg commented Jan 31, 2026 • edited by greptile-apps bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Problem

Solution

Changes

Configuration

Greptile Overview

Greptile Summary

Confidence Score: 4/5

Uh oh!

greptile-apps bot left a comment

Choose a reason for hiding this comment

Uh oh!

greptile-apps bot Jan 31, 2026

Choose a reason for hiding this comment

Uh oh!

greptile-apps bot Jan 31, 2026

Choose a reason for hiding this comment

Uh oh!

greptile-apps bot Jan 31, 2026

Choose a reason for hiding this comment

Uh oh!

vercel bot commented Feb 22, 2026

Uh oh!

obviyus commented Feb 22, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Glucksberg commented Jan 31, 2026 •

edited by greptile-apps bot

Loading