openclaw - 💡(How to fix) Fix [Bug]: Discord /gateway/bot metadata lookup times out at 10s starting ~2026-04-27 (raw HTTP latency is fine) [2 comments, 3 participants]

Summary

Starting around 2026-04-27, the Discord provider's /gateway/bot metadata fetch began timing out frequently (gateway metadata lookup failed transiently; using default gateway url ... gateway metadata timeout), even though raw HTTP latency to discord.com from the same host is healthy. The 10s hardcoded DISCORD_GATEWAY_INFO_TIMEOUT_MS is no longer a comfortable margin against whatever the bot's fetch() is doing.

Environment

• [email protected] (npm-global install)
• Node: system /usr/bin/node
• Linux (Debian-family), ens18 + LAN-resolver DNS
• Multiple Discord bots configured under one gateway process (chief, default, security, opencoder, reviewer, architect, notifier, researcher)

Evidence

gateway metadata lookup failed transiently occurrences per day (from journalctl --user -u openclaw-gateway.service):

Sharp inflection on Apr 27 with no version change on this host (gateway has been on 2026.4.26 since install).

Raw HTTP probe to the same endpoint from the same host while warnings are firing:

$ for i in 1 2 3; do curl -o /dev/null -s -w "attempt $i: %{http_code} dns=%{time_namelookup}s connect=%{time_connect}s tls=%{time_appconnect}s total=%{time_total}s\n" --max-time 10 https://discord.com/api/v10/gateway/bot; done
attempt 1: 401 dns=0.002s connect=0.007s tls=0.052s total=0.124s
attempt 2: 401 dns=0.002s connect=0.008s tls=0.053s total=0.117s
attempt 3: 401 dns=0.002s connect=0.007s tls=0.050s total=0.172s

401 is the expected unauthenticated response — the point is total time is ~120ms, well under the 10s timeout. So the underlying network path and TLS handshake are fine.

Hypotheses

The mismatch (curl: ~120ms; bot's fetch: 10s timeout) suggests the issue is in how the bot's fetchImpl reuses connections, not the network:

1. undici HTTP/2 session stuck. If the bot's fetch reuses a long-lived H2 session that's been half-closed by Cloudflare or stalled by a window-update issue, every subsequent request hangs until the per-request timeout, while a fresh connection (curl) succeeds instantly. The pattern — periodic, host-wide, unaffected by the network — fits this exactly.
2. Per-bot-token slow path on Discord's side introduced ~Apr 27. Less likely given that other Discord traffic from these bots (gateway WS, REST messages) is healthy; only /gateway/bot chronically times out.

(1) is more consistent with the observation that the WS gateway connections themselves stay healthy on this host outside of an unrelated 14-minute upstream blip on Apr 28 09:11–09:25 EDT.

Code references

• dist/extensions/discord/provider-*.js:
  • const DISCORD_GATEWAY_INFO_TIMEOUT_MS = 1e4; — hardcoded 10s constant
  • const timeoutMs = Math.max(1, params.timeoutMs ?? DISCORD_GATEWAY_INFO_TIMEOUT_MS);
  • Discord API /gateway/bot timed out after ${timeoutMs}ms ... cause: new Error("gateway metadata timeout")

The fallback path (using default gateway url) is working as designed and the bots stay online — this is log noise rather than a hard outage. But it floods journald and masks real failures.

Suggestions

1. Bump DISCORD_GATEWAY_INFO_TIMEOUT_MS default to ~30s, or expose it as an env var / config (OPENCLAW_DISCORD_GATEWAY_INFO_TIMEOUT_MS).
2. Force a fresh dispatcher / disable H2 connection reuse for the /gateway/bot request specifically (undici.fetch(..., { dispatcher: new Agent({ pipelining: 0, allowH2: false }) })), since the response is small, infrequent, and benefits nothing from reuse.
3. Demote the warning to debug-level once retries succeed, or rate-limit it (one log line per minute), so a sustained period of failures doesn't drown the log.

Happy to share more journal excerpts or test a patched build if helpful.