PR #74549: Fix Telegram EHOSTUNREACH gateway crash

• Repository: openclaw/openclaw
• Author: HemantSudarshan
• State: closed | merged: True
• Link: https://github.com/openclaw/openclaw/pull/74549

Description (problem / solution / changelog)

Summary

• Problem: a raw socket-level Telegram EHOSTUNREACH can reach the process uncaughtException handler and terminate the gateway even though the same transient network class is already recoverable elsewhere.
• Why it matters: temporary Telegram API reachability blips should not kill the OpenClaw gateway.
• What changed: shared uncaught-exception classification now treats transient network errors as benign, matching the existing unhandled-rejection behavior.
• What did NOT change (scope boundary): no Telegram request retry policy, fetch fallback dispatcher behavior, or security-audit logic changed.

Change Type (select all)

• Bug fix
• Feature
• Refactor required for the fix
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Closes #74540
• Related #
• This PR fixes a bug or regression

Root Cause (if applicable)

• Root cause: process-level uncaught exceptions only treated a tiny broken-pipe set as non-fatal, while transient network errors were only suppressed on the unhandled-rejection path.
• Missing detection / guardrail: no test covered raw EHOSTUNREACH reaching the CLI uncaught-exception handler.
• Contributing context (if known): Telegram transport already handles EHOSTUNREACH when it is delivered as a fetch rejection, but undici/socket errors can also surface as uncaught exceptions.

Regression Test Plan (if applicable)

• Coverage level that should have caught this:
  • Unit test
  • Seam / integration test
  • End-to-end test
  • Existing coverage already sufficient
• Target test or file: src/infra/unhandled-rejections.test.ts, src/cli/run-main.exit.test.ts
• Scenario the test should lock in: raw connect EHOSTUNREACH ... exceptions are logged as non-fatal and do not call process.exit(1).
• Why this is the smallest reliable guardrail: the failure path is the shared uncaught-exception classifier and CLI handler, not Telegram fetch retry dispatch itself.
• Existing test that already covers this (if any): Telegram fetch/network tests already cover promise-rejection fallback behavior.
• If no new test is added, why not: N/A

User-visible / Behavior Changes

Transient network uncaught exceptions are logged as non-fatal warnings instead of shutting down the CLI/gateway process.

Diagram (if applicable)

Before:
[Telegram socket EHOSTUNREACH] -> [uncaughtException] -> [process exit]

After:
[Telegram socket EHOSTUNREACH] -> [transient network classification] -> [warn and continue]

Security Impact (required)

• New permissions/capabilities? (Yes/No) No
• Secrets/tokens handling changed? (Yes/No) No
• New/changed network calls? (Yes/No) No
• Command/tool execution surface changed? (Yes/No) No
• Data access scope changed? (Yes/No) No
• If any Yes, explain risk + mitigation: N/A

Repro + Verification

Environment

• OS: Windows local checkout
• Runtime/container: Node 22 via repo scripts
• Model/provider: N/A
• Integration/channel (if any): Telegram network failure path
• Relevant config (redacted): N/A

Steps

1. Simulate a raw uncaught EHOSTUNREACH error.
2. Pass it through isBenignUncaughtExceptionError() and the CLI uncaught-exception handler.
3. Verify the handler warns and does not exit.

Expected

• Transient Telegram host-unreachable failures do not terminate the gateway process.

Actual

• Fixed by this PR.

Evidence

• Failing test/log before + passing after
• Trace/log snippets
• Screenshot/recording
• Perf numbers (if relevant)

Human Verification (required)

What you personally verified (not just CI), and how:

• Verified scenarios:
  • pnpm test src/infra/unhandled-rejections.test.ts -t "treats raw transient network uncaught exceptions as benign" -- --reporter=verbose
  • pnpm test src/infra/unhandled-rejections.test.ts src/cli/run-main.exit.test.ts -- --reporter=verbose
  • pnpm test extensions/telegram/src/fetch.test.ts extensions/telegram/src/network-errors.test.ts -- --reporter=verbose
  • pnpm check:changed
  • git diff --check
• Edge cases checked: generic errors still are not benign; transient SQLite remains rejected for uncaught-exception suppression; Telegram fetch fallback tests still pass.
• What you did not verify: live Telegram outage against the real Bot API.

Note: pnpm test:changed was run and failed in three unrelated Windows baseline cases. I stashed this PR patch and reran the exact failing files on the unmodified base; the same failures reproduced:

• src/crestodian/rescue-message.test.ts expects /tmp/work but receives C:\tmp\work.
• src/crestodian/operations.test.ts expects /tmp/work but receives C:\tmp\work.
• src/security/audit-sandbox-docker-config.test.ts misclassifies a Windows short home path as non-absolute.

Review Conversations

• I replied to or resolved every bot review conversation I addressed in this PR.
• I left unresolved only the conversations that still need reviewer or maintainer judgment.

If a bot review conversation is addressed by this PR, resolve that conversation yourself. Do not leave bot review conversation cleanup for maintainers.

Compatibility / Migration

• Backward compatible? (Yes/No) Yes
• Config/env changes? (Yes/No) No
• Migration needed? (Yes/No) No
• If yes, exact upgrade steps: N/A

Risks and Mitigations

• Risk: continuing after a transient uncaught exception may leave a single integration operation failed.
  • Mitigation: this matches the existing unhandled-rejection policy for transient network errors and keeps fatal/config errors exiting as before.

Changed files

• CHANGELOG.md (modified, +1/-0)
• extensions/telegram/src/monitor.test.ts (modified, +86/-19)
• extensions/telegram/src/monitor.ts (modified, +22/-12)
• src/cli/run-main.exit.test.ts (modified, +5/-3)
• src/infra/unhandled-rejections.test.ts (modified, +9/-1)
• src/infra/unhandled-rejections.ts (modified, +33/-0)