openclaw - ✅(Solved) Fix [Bug]: Telegram safe-send retry misses grammY Network request failed envelope [1 pull requests, 2 comments, 3 participants]

Official PRs (…)
ON THIS PAGE

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#74203Fetched 2026-04-30 06:27:29
View on GitHub
Comments
2
Participants
3
Timeline
6
Reactions
2
Timeline (top)
cross-referenced ×3commented ×2closed ×1

OpenClaw 2026.4.26 still treats grammY HttpError: Network request for 'sendMessage' failed! as a terminal Telegram delivery failure in the final reply path, even though this is a transient pre-response network envelope that should be eligible for bounded safe retry.

Error Message

2026-04-29T14:49:51.536+08:00 [telegram] editMessage failed: Network request for 'editMessageText' failed! 2026-04-29T14:49:52.537+08:00 [telegram] sendMessage failed: Network request for 'sendMessage' failed! 2026-04-29T14:49:52.538+08:00 [telegram] final reply failed: HttpError: Network request for 'sendMessage' failed!

2026-04-29T15:01:19.484+08:00 [telegram] sendMessage failed: Network request for 'sendMessage' failed! 2026-04-29T15:01:19.486+08:00 [telegram] final reply failed: HttpError: Network request for 'sendMessage' failed! 2026-04-29T15:01:20.483+08:00 [telegram] sendMessage failed: Network request for 'sendMessage' failed! 2026-04-29T15:01:20.484+08:00 [telegram] message processing failed: HttpError: Network request for 'sendMessage' failed!

Root Cause

  • Affected users/systems/channels: Telegram users on interactive final replies and group/topic replies.
  • Severity: High for Telegram usage because the agent can compute a final answer but Telegram never receives it.
  • Frequency: Intermittent; observed multiple times during a Telegram Bot API network-instability window on 2026-04-29.
  • Consequence: final replies can be dropped or message processing can fail after the model has completed, making the bot appear unresponsive.

Fix Action

Fix / Workaround

  1. Run OpenClaw 2026.4.26 with Telegram enabled in polling mode.
  2. Trigger an interactive Telegram reply while the Bot API path is intermittently failing.
  3. Observe gateway logs containing sendChatAction failed followed by sendMessage failed: Network request for 'sendMessage' failed!.
  4. Observe the final reply path logs final reply failed: HttpError: Network request for 'sendMessage' failed! or message processing failed: HttpError: Network request for 'sendMessage' failed!.
  5. Inspect the Telegram send retry classification in the installed 2026.4.26 bundle before any local patch: the retry helper recognizes low-level pre-connect codes and has a grammY wrapper regex for Network request ... failed after..., but the observed top-level grammY message is the simpler Network request for 'sendMessage' failed!.

Static inspection of the installed 2026.4.26 bundle before local patch:

  • Telegram send path uses strict retry: shouldRetry: (err) => isSafeToRetrySendError(err) || isTelegramRateLimitError(err) strictShouldRetry: true
  • isSafeToRetrySendError checks recognized pre-connect error codes.
  • The grammY top-level wrapper regex present in the bundle matched: /^network request(?:\s+for\s+["']?[^"']+["']?)?\s+failed\s+after\b.*[!.]?$/i
  • The observed runtime message was: Network request for 'sendMessage' failed!
  • That observed message does not contain "failed after", so it is not covered by that wrapper regex.

Local workaround tested outside upstream: expanding the safe retry wrapper check to also match the plain `Network request for '<method>' failed!` message allows the existing bounded send retry path to classify this envelope as retryable. This does not replace the durable-delivery work tracked in #50040.

PR fix notes

PR #74230: fix(telegram): classify plain grammY network envelope as safe to retry for sends

Description (problem / solution / changelog)

Summary

Extends isSafeToRetrySendError to recognize grammY's plain pre-response network envelope (Network request for '<method>' failed!) when it wraps a TypeError("fetch failed"), classifying this combination as safe to retry for non-idempotent Telegram send operations.

Problem

When grammY wraps a TypeError("fetch failed") without a specific pre-connect error code in the cause chain, the resulting HttpError("Network request for 'sendMessage' failed!") was not classified as retryable by isSafeToRetrySendError. This caused final Telegram replies to fail permanently on transient network issues even though the message was never delivered to Telegram.

The existing code:

  • isSafeToRetrySendError only matched PRE_CONNECT_ERROR_CODES (ECONNREFUSED, ENOTFOUND, etc.)
  • GRAMMY_NETWORK_REQUEST_FAILED_AFTER_RE required "failed after" in the message
  • The plain envelope Network request for '<method>' failed! (without "after") was not covered

Fix

Adds a second detection pass in isSafeToRetrySendError:

  1. A new regex GRAMMY_NETWORK_REQUEST_FAILED_RE matches the plain grammY envelope (without "after")
  2. When the plain envelope is detected, requires a nested ALWAYS_RECOVERABLE_MESSAGES match ("fetch failed" / "typeerror: fetch failed") to confirm the request never received a response
  3. This two-part check avoids false positives from unexpected future grammY error shapes

Safety

The fix is conservative:

  • Only triggers when both the outer grammY envelope pattern and an inner fetch-level failure are present
  • TypeError("fetch failed") means the HTTP request threw before any response — no data was sent to Telegram
  • Does not match broader snippet-level errors (e.g. "socket hang up") which could occur after partial delivery
  • Existing pre-connect code detection continues to work as before

Tests

4 new test cases added to isSafeToRetrySendError:

  • ✅ Plain grammY envelope + TypeError("fetch failed") → safe to retry
  • ✅ Plain grammY envelope for editMessageText + TypeError("fetch failed") → safe to retry
  • ✅ Plain grammY envelope + non-fetch inner error → NOT safe to retry
  • ✅ Plain grammY envelope + snippet-only inner error → NOT safe to retry

All 45 network-errors tests and 87 send tests pass.

Verification

pnpm test extensions/telegram/src/network-errors.test.ts  # 45 passed
pnpm test extensions/telegram/src/send.test.ts            # 87 passed
pnpm exec oxfmt --check --threads=1 extensions/telegram/src/network-errors.ts extensions/telegram/src/network-errors.test.ts  # clean

Closes #74203

Changed files

  • extensions/telegram/src/network-errors.test.ts (modified, +30/-0)
  • extensions/telegram/src/network-errors.ts (modified, +42/-1)

Code Example

2026-04-29T14:49:51.536+08:00 [telegram] editMessage failed: Network request for 'editMessageText' failed!
2026-04-29T14:49:52.537+08:00 [telegram] sendMessage failed: Network request for 'sendMessage' failed!
2026-04-29T14:49:52.538+08:00 [telegram] final reply failed: HttpError: Network request for 'sendMessage' failed!

2026-04-29T15:01:19.484+08:00 [telegram] sendMessage failed: Network request for 'sendMessage' failed!
2026-04-29T15:01:19.486+08:00 [telegram] final reply failed: HttpError: Network request for 'sendMessage' failed!
2026-04-29T15:01:20.483+08:00 [telegram] sendMessage failed: Network request for 'sendMessage' failed!
2026-04-29T15:01:20.484+08:00 [telegram] message processing failed: HttpError: Network request for 'sendMessage' failed!

---

OpenClaw version:
OpenClaw 2026.4.26 (be8c246)

OS:
Ubuntu 24.04.4 LTS

Observed gateway logs:
2026-04-29T14:49:51.536+08:00 [telegram] editMessage failed: Network request for 'editMessageText' failed!
2026-04-29T14:49:52.537+08:00 [telegram] sendMessage failed: Network request for 'sendMessage' failed!
2026-04-29T14:49:52.538+08:00 [telegram] final reply failed: HttpError: Network request for 'sendMessage' failed!
2026-04-29T15:01:19.484+08:00 [telegram] sendMessage failed: Network request for 'sendMessage' failed!
2026-04-29T15:01:19.486+08:00 [telegram] final reply failed: HttpError: Network request for 'sendMessage' failed!
2026-04-29T15:01:20.483+08:00 [telegram] sendMessage failed: Network request for 'sendMessage' failed!
2026-04-29T15:01:20.484+08:00 [telegram] message processing failed: HttpError: Network request for 'sendMessage' failed!

Static inspection of the installed 2026.4.26 bundle before local patch:
- Telegram send path uses strict retry:
  shouldRetry: (err) => isSafeToRetrySendError(err) || isTelegramRateLimitError(err)
  strictShouldRetry: true
- isSafeToRetrySendError checks recognized pre-connect error codes.
- The grammY top-level wrapper regex present in the bundle matched:
  /^network request(?:\s+for\s+["']?[^"']+["']?)?\s+failed\s+after\b.*[!.]?$/i
- The observed runtime message was:
  Network request for 'sendMessage' failed!
- That observed message does not contain "failed after", so it is not covered by that wrapper regex.
RAW_BUFFERClick to expand / collapse

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

OpenClaw 2026.4.26 still treats grammY HttpError: Network request for 'sendMessage' failed! as a terminal Telegram delivery failure in the final reply path, even though this is a transient pre-response network envelope that should be eligible for bounded safe retry.

Steps to reproduce

  1. Run OpenClaw 2026.4.26 with Telegram enabled in polling mode.
  2. Trigger an interactive Telegram reply while the Bot API path is intermittently failing.
  3. Observe gateway logs containing sendChatAction failed followed by sendMessage failed: Network request for 'sendMessage' failed!.
  4. Observe the final reply path logs final reply failed: HttpError: Network request for 'sendMessage' failed! or message processing failed: HttpError: Network request for 'sendMessage' failed!.
  5. Inspect the Telegram send retry classification in the installed 2026.4.26 bundle before any local patch: the retry helper recognizes low-level pre-connect codes and has a grammY wrapper regex for Network request ... failed after..., but the observed top-level grammY message is the simpler Network request for 'sendMessage' failed!.

Expected behavior

For pre-response Telegram Bot API transport failures reported by grammY as Network request for '<method>' failed!, OpenClaw should classify the error as retryable when the request is safe under the existing non-idempotent-send guardrails, then perform bounded backoff retry before failing the final reply.

Actual behavior

The final Telegram reply can be computed by the agent but not delivered. The gateway logs a top-level grammY HttpError and treats the delivery as failed:

2026-04-29T14:49:51.536+08:00 [telegram] editMessage failed: Network request for 'editMessageText' failed!
2026-04-29T14:49:52.537+08:00 [telegram] sendMessage failed: Network request for 'sendMessage' failed!
2026-04-29T14:49:52.538+08:00 [telegram] final reply failed: HttpError: Network request for 'sendMessage' failed!

2026-04-29T15:01:19.484+08:00 [telegram] sendMessage failed: Network request for 'sendMessage' failed!
2026-04-29T15:01:19.486+08:00 [telegram] final reply failed: HttpError: Network request for 'sendMessage' failed!
2026-04-29T15:01:20.483+08:00 [telegram] sendMessage failed: Network request for 'sendMessage' failed!
2026-04-29T15:01:20.484+08:00 [telegram] message processing failed: HttpError: Network request for 'sendMessage' failed!

OpenClaw version

2026.4.26 (be8c246)

Operating system

Ubuntu 24.04.4 LTS

Install method

npm global

Model

Not model-dependent. The gateway was running openai-codex/gpt-5.5 when the observed final reply failures occurred.

Provider / routing chain

openclaw gateway -> Telegram channel provider / grammY -> Telegram Bot API through local network/proxy routing

Additional provider/model setup details

The model run completes; the failure is in Telegram delivery after the assistant reply is ready. Both Telegram default and group providers were enabled and running in polling mode. openclaw gateway health returned OK after restart, while openclaw channels status --probe showed Telegram providers running but probe failed during the same network-instability window.

Logs, screenshots, and evidence

OpenClaw version:
OpenClaw 2026.4.26 (be8c246)

OS:
Ubuntu 24.04.4 LTS

Observed gateway logs:
2026-04-29T14:49:51.536+08:00 [telegram] editMessage failed: Network request for 'editMessageText' failed!
2026-04-29T14:49:52.537+08:00 [telegram] sendMessage failed: Network request for 'sendMessage' failed!
2026-04-29T14:49:52.538+08:00 [telegram] final reply failed: HttpError: Network request for 'sendMessage' failed!
2026-04-29T15:01:19.484+08:00 [telegram] sendMessage failed: Network request for 'sendMessage' failed!
2026-04-29T15:01:19.486+08:00 [telegram] final reply failed: HttpError: Network request for 'sendMessage' failed!
2026-04-29T15:01:20.483+08:00 [telegram] sendMessage failed: Network request for 'sendMessage' failed!
2026-04-29T15:01:20.484+08:00 [telegram] message processing failed: HttpError: Network request for 'sendMessage' failed!

Static inspection of the installed 2026.4.26 bundle before local patch:
- Telegram send path uses strict retry:
  shouldRetry: (err) => isSafeToRetrySendError(err) || isTelegramRateLimitError(err)
  strictShouldRetry: true
- isSafeToRetrySendError checks recognized pre-connect error codes.
- The grammY top-level wrapper regex present in the bundle matched:
  /^network request(?:\s+for\s+["']?[^"']+["']?)?\s+failed\s+after\b.*[!.]?$/i
- The observed runtime message was:
  Network request for 'sendMessage' failed!
- That observed message does not contain "failed after", so it is not covered by that wrapper regex.

Impact and severity

  • Affected users/systems/channels: Telegram users on interactive final replies and group/topic replies.
  • Severity: High for Telegram usage because the agent can compute a final answer but Telegram never receives it.
  • Frequency: Intermittent; observed multiple times during a Telegram Bot API network-instability window on 2026-04-29.
  • Consequence: final replies can be dropped or message processing can fail after the model has completed, making the bot appear unresponsive.

Additional information

Related issues:

  • #51525 was closed as completed for the older grammY retry-envelope gap. The remaining 2026.4.26 behavior appears narrower: current code recognizes a failed after... grammY wrapper shape, but not the observed Network request for '<method>' failed! shape.
  • #50040 tracks the broader durable Telegram outbound delivery problem. This report is intentionally narrower: bounded safe retry classification for the observed grammY pre-response network envelope before the broader persistent queue/recovery design is implemented.

Local workaround tested outside upstream: expanding the safe retry wrapper check to also match the plain Network request for '<method>' failed! message allows the existing bounded send retry path to classify this envelope as retryable. This does not replace the durable-delivery work tracked in #50040.

extent analysis

TL;DR

Update the retry helper's grammY wrapper regex to match the Network request for '<method>' failed! error message to enable bounded safe retry for pre-response Telegram Bot API transport failures.

Guidance

  • Review the isSafeToRetrySendError function to ensure it correctly handles the Network request for '<method>' failed! error message.
  • Update the grammY wrapper regex to include the observed error message shape, e.g., /^Network request for '.*' failed!$/i.
  • Verify that the updated regex correctly matches the error message and triggers the retry mechanism.
  • Test the updated code with the local workaround to ensure it resolves the issue.

Example

const retryRegex = /^Network request for '.*' failed!$/i;
// ...
shouldRetry: (err) => retryRegex.test(err.message) || isTelegramRateLimitError(err)

Notes

The provided workaround has been tested locally, but it's essential to verify its effectiveness in the production environment. Additionally, this fix does not address the broader durable-delivery problem tracked in #50040.

Recommendation

Apply the workaround by updating the grammY wrapper regex to match the observed error message shape, as it has been tested locally and can provide a temporary solution to 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…

FAQ

Expected behavior

For pre-response Telegram Bot API transport failures reported by grammY as Network request for '<method>' failed!, OpenClaw should classify the error as retryable when the request is safe under the existing non-idempotent-send guardrails, then perform bounded backoff retry before failing the final reply.

Still need to ship something?

×6

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

Back to top recommendations

TRENDING

openclaw - ✅(Solved) Fix [Bug]: Telegram safe-send retry misses grammY Network request failed envelope [1 pull requests, 2 comments, 3 participants]