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)
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)