Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix [Bug]: Discord breaks on OpenClaw ≥ 2026.4.29 (WSL2), OK on 2026.4.23 [1 pull requests, 1 comments, 2 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#77103•Fetched 2026-05-05 05:52:09
View on GitHub
Comments
1
Participants
2
Timeline
11
Reactions
2
Author
Suited78Suited78
Participants
clawsweeper[bot]clawsweeper[bot]Suited78Suited78
Timeline (top)
subscribed ×4mentioned ×3closed ×1commented ×1

On WSL2, upgrading OpenClaw from 2026.4.23 to ≥2026.4.29 breaks the Discord provider due to REST API startup timeouts (despite Discord being reachable via curl), making Discord messaging unusable until rollback.

Root Cause

On WSL2, upgrading OpenClaw from 2026.4.23 to ≥2026.4.29 breaks the Discord provider due to REST API startup timeouts (despite Discord being reachable via curl), making Discord messaging unusable until rollback.

Fix Action

Fixed

PR fix notes

PR #77129: fix(discord): avoid blocking startup on probe

Description (problem / solution / changelog)

Summary

  • Make Discord startup fire the bot/application probe asynchronously so /users/@me timeouts do not block monitor startup.
  • Keep probe-based status enrichment and Message Content Intent warnings when the probe later completes.
  • Add a regression test proving monitor startup proceeds while the startup probe is still pending.

Fixes #77103.

Verification

  • pnpm exec oxfmt --check --threads=1 extensions/discord/src/channel.ts extensions/discord/src/channel.test.ts
  • pnpm test extensions/discord/src/channel.test.ts
  • pnpm check:changelog-attributions
  • git diff --check origin/main...HEAD

Changed files

  • CHANGELOG.md (modified, +1/-0)
  • extensions/discord/src/channel.test.ts (modified, +98/-4)
  • extensions/discord/src/channel.ts (modified, +63/-32)
  • src/plugin-sdk/channel-entry-contract.test.ts (modified, +3/-0)
  • src/plugin-sdk/facade-loader.test.ts (modified, +1/-1)
  • src/plugins/loader.ts (modified, +5/-16)
  • src/plugins/plugin-module-loader-cache.ts (modified, +38/-0)
  • src/plugins/plugin-sdk-dist-alias.ts (modified, +2/-1)
RAW_BUFFERClick to expand / collapse

Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

On WSL2, upgrading OpenClaw from 2026.4.23 to ≥2026.4.29 breaks the Discord provider due to REST API startup timeouts (despite Discord being reachable via curl), making Discord messaging unusable until rollback.

Steps to reproduce

After upgrading to ≥ 2026.4.29, Discord provider fails to become usable / Discord comms break. Rolling back to 2026.4.23 immediately restores Discord comms.

Expected behavior

Discord provider should be stable across updates; if a REST probe fails transiently it should retry/backoff and not permanently break the channel, and should log actionable diagnostics.

Actual behavior

OpenClaw shows a startup REST probe timing out: fetchWithTimeout timeout hitting https://discord.com/api/v10/users/@me Discord provider starts but does not stabilize.

From inside the same WSL2 environment, Discord is reachable: curl -I https://discord.com/api/v10/users/@me → HTTP 401 quickly (expected) curl -I https://discord.com/api/v10/gateway/bot → HTTP 401 quickly getent hosts discord.com resolves normally

So this looks like an OpenClaw/Node fetch (undici) regression or WSL2-specific interaction (proxy/IPv6/DNS order/timeouts), not a general connectivity block.

OpenClaw version

2026.4.29 and 2026.5.2

Operating system

OS: Windows + WSL2

Install method

npm global

Model

openai-codex/gpt-5.2

Provider / routing chain

Discord (OpenClaw gateway) → Discord REST API (discord.com/api/v10) + Discord Gateway (wss://gateway.discord.gg)

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Impact and severity

High, core channel integration broken beyond 2026.4.23

Additional information

Last known good version 2026.4.23.

Request / likely fix areas Make Discord startup probe resilient (retries + backoff; don’t hard-fail on one timeout) Expose configurable Discord REST timeout Improve diagnostics: show effective timeout, whether proxy env vars are detected, IPv4/IPv6 selection, DNS results inside Node/undici Consider WSL2-specific networking behavior (IPv6 stalls / proxy detection differences vs curl)

extent analysis

TL;DR

The Discord provider in OpenClaw may be fixed by making the Discord startup probe more resilient with retries and backoff, or by exposing a configurable Discord REST timeout.

Guidance

  • Investigate the difference in behavior between curl and OpenClaw's fetchWithTimeout to understand why curl can reach Discord while OpenClaw times out.
  • Consider implementing retries with exponential backoff for the Discord startup probe to prevent permanent failure on a single timeout.
  • Expose a configurable Discord REST timeout to allow for adjustments based on the specific environment.
  • Review WSL2-specific networking behavior, such as IPv6 stalls or proxy detection differences, that might affect OpenClaw's connectivity.

Example

No specific code example is provided due to the lack of direct code references in the issue, but an example of implementing retries with backoff in JavaScript could involve using a library like async-retry or manually implementing a retry mechanism with setTimeout.

Notes

The issue seems to be related to the interaction between OpenClaw, Node's undici fetch implementation, and WSL2's networking environment. The exact cause and best solution may require further investigation into these components and their configurations.

Recommendation

Apply a workaround by implementing retries with backoff for the Discord startup probe, as this is a directly implied potential fix from the issue description and can help mitigate the problem without waiting for a full version update.

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

Discord provider should be stable across updates; if a REST probe fails transiently it should retry/backoff and not permanently break the channel, and should log actionable diagnostics.

#api#ssr#permission error#memory optimization#batch processing

Still need to ship something?

×6

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

Back to top recommendations

TRENDING