openclaw - ✅(Solved) Fix [Bug]: Discord channel hangs on "awaiting gateway readiness" after upgrade to 2026.5.4 [3 pull requests, 2 comments, 3 participants]

openclaw2026-05-05 22:26:50

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.

GitHub issue URL

Helpful · Quick feedback

GitHub stats

openclaw/openclaw#78104•Fetched 2026-05-06 06:16:52

View on GitHub

Comments

Participants

Timeline

Reactions

Author

Participants

Timeline (top)

cross-referenced ×3commented ×2labeled ×2closed ×1

After upgrading to OpenClaw 2026.5.4 GA + @openclaw/discord 2026.5.4 GA, the Discord channel still exhibits the same silent "awaiting gateway readiness" hang previously reported on 2026-05-04 against 2026.5.3-1; one outbound reply lands at startup, then all subsequent outbound replies are silently dropped.

Error Message

Send a message in webchat that triggers a reply mirrored to Discord. First reply lands. Subsequent replies are silently dropped — no error surfaced to user, no error in logs. After every gateway start or channel hot reload, the Discord plugin logs the bot probe + intent + client init lines, then halts at discord client initialized; awaiting gateway readiness. No ready, no shard connect, no error log line. ~2.7s later, fetchWithTimeout warns against https://discord.com/api/v10/users/@me (timeoutMs=2500 elapsedMs=2501; fetch timeout reached; aborting operation). Outbound replies the agent emits are silently dropped after the first message post-restart. Inbound Discord messages still route to the agent and create sessions normally. This matches the failure mode in the prior report: REST works once, the persistent gateway WebSocket lifecycle never reaches ready, and the suspected registration.catch(() => {}) swallow in OpenClawGatewayPlugin.registerClient continues to hide the underlying error. 2026-05-05T17:23:51 fetch-timeout WARN url=https://discord.com/api/v10/users/@me timeoutMs=2500 elapsedMs=2501 — fetch timeout reached; aborting operation (no "ready" event, no shard connect, no error follow-up)

Severity: High — blocks Discord as a working agent channel. Outbound replies look "sent" to the agent (no error surfaced) but never arrive in Discord. Invisible failures are worse than hard errors.

Root Cause

NODE_DEBUG=undici,http,tls trace from the prior report showed the gateway process opening REST connections to discord.com (HTTP 200 on /users/@me and /oauth2/applications/@me) and zero WebSocket activity to gateway.discord.gg. We did not re-instrument on 2026.5.4 because the external symptom is identical.

Fix Action

Fix / Workaround

Plugin: @openclaw/[email protected] GA, peer dep openclaw>=2026.5.4 (matches). Workaround: set channels.discord.enabled=false and fall back to webchat/Telegram.

Last known good plugin version: unknown on this host — bug was first observed on 2026-05-04 immediately after a clean install on 2026.5.3-1, and reproduces on every plugin version tried since.
First known bad version: @openclaw/[email protected] (also has a separate missing-dist/ packaging issue).
@openclaw/[email protected] separate bug (already in the prior report): imports formatChannelProgressDraftLineForEntry from openclaw/plugin-sdk/channel-streaming, which does not exist in 2026.5.3-1. Prevents outbound delivery entirely with a SyntaxError. Not what we're hitting on GA — flagged here so peer compatibility can be bounded properly upstream.
Workaround applied today: disabled channels.discord.enabled on this host and restarted the gateway. Falling back to webchat/Telegram until the WS readiness path is fixed.
Local writeup with NODE_DEBUG output and line-level plugin pointers is available; happy to attach on request.

PR fix notes

PR #78132: fix: avoid stalled Discord gateway registration

Repository: openclaw/openclaw
Author: bryce-d-greybeard
State: closed | merged: False
Link: https://github.com/openclaw/openclaw/pull/78132

Description (problem / solution / changelog)

Summary

fix Discord gateway registration so stale isConnecting=true without an active socket does not suppress super.registerClient(client)
keep the existing guard for an actual already-started gateway WebSocket
update the regression test to cover the stale bookkeeping case from #78104

Fixes #78104.

Tests

PATH="/tmp/openclaw-pnpm-shim:$PATH" pnpm test extensions/discord/src/monitor/provider.proxy.test.ts extensions/discord/src/monitor/gateway-plugin.test.ts extensions/discord/src/internal/gateway.test.ts extensions/discord/src/monitor/provider.lifecycle.test.ts
git diff --check
PATH="/tmp/openclaw-pnpm-shim:$PATH" node scripts/check-changed.mjs
PATH="/tmp/openclaw-pnpm-shim:$PATH" pnpm exec oxfmt --check --threads=1 extensions/discord/src/monitor/gateway-plugin.ts extensions/discord/src/monitor/provider.proxy.test.ts

Changed files

extensions/discord/src/monitor/gateway-plugin.ts (modified, +4/-1)
extensions/discord/src/monitor/provider.proxy.test.ts (modified, +1/-1)

PR #19: fix(discord): clear stale isConnecting state before gateway re-registration

Repository: suboss87/openclaw
Author: suboss87
State: open | merged: False
Link: https://github.com/suboss87/openclaw/pull/19

Description (problem / solution / changelog)

Summary

Fixes #78104 — Discord channel hangs on "awaiting gateway readiness" after a prior incomplete registration leaves isConnecting=true on the GatewayPlugin instance.

Root cause: registerClientInternal checked hasGatewaySocketStarted(this) after an async metadata fetch and returned early if true. That guard was intended to skip re-registration when the lifecycle timeout started a socket during the fetch. But it also fired when isConnecting=true was left over from a prior incomplete registration (e.g. a handshake that started but was never confirmed). In that case connect() would return early due to its own if (this.isConnecting) return guard, so no fresh connection was ever opened and startup remained stuck waiting for isConnected.

Fix: Snapshot hasGatewaySocketStarted(this) before the async metadata fetch:

If socketStartedBeforeFetch=false and socket state appears after the fetch, a concurrent lifecycle connect() raced in — skip re-registration as before.
If socketStartedBeforeFetch=true, the socket state is stale from a prior registration round — call this.disconnect() to clear isConnecting and ws, then call super.registerClient(client) to open a fresh connection.

Changes

extensions/discord/src/monitor/gateway-plugin.ts: snapshot socket state before the metadata fetch and call disconnect() before super.registerClient() when stale state is detected.
extensions/discord/src/monitor/gateway-plugin.test.ts: add disconnect() to the mock GatewayPlugin base class; add tests verifying stale-state clearance and no spurious disconnect on a clean first registration.
CHANGELOG.md: add fix entry.

Test plan

pnpm test extensions/discord/src/monitor/gateway-plugin.test.ts — 17 tests pass (2 new)
pnpm test extensions/discord/src/monitor/provider.proxy.test.ts — 21 tests pass (no regressions)
pnpm test extensions/discord/src/monitor/provider.startup.test.ts — 9 tests pass
pnpm test extensions/discord/src/monitor/gateway-supervisor.test.ts extensions/discord/src/monitor/provider.lifecycle.test.ts — 26 tests pass
pnpm exec oxfmt --check clean on all changed files

Generated by Claude Code

Changed files

CHANGELOG.md (modified, +1/-0)
extensions/discord/src/monitor/gateway-plugin.test.ts (modified, +64/-0)
extensions/discord/src/monitor/gateway-plugin.ts (modified, +13/-3)

PR #78227: fix(discord): treat bare isConnecting=true as stale, not started gateway

Repository: openclaw/openclaw
Author: Beandon13
State: open | merged: False
Link: https://github.com/openclaw/openclaw/pull/78227

Description (problem / solution / changelog)

Fixes #78104.

Root cause

OpenClawGatewayPlugin.registerClient short-circuits on hasGatewaySocketStarted when an external connect races with the gateway-info metadata fetch (#52372). That helper currently returns true if the underlying plugin has either an actual ws reference or its isConnecting flag set to true.

isConnecting=true without an attached socket is not a started transport — it's stale bookkeeping left over from a previous registration attempt that rejected before connect(false) ran and never cleared the flag. Once that happens, every gateway boot from that point on sees the stale flag, skips super.registerClient, and the daemon logs discord client initialized; awaiting gateway readiness forever. That's exactly the symptom in #78104: REST works, the gateway WebSocket lifecycle never reaches ready, no error is surfaced, and outbound replies are silently dropped after the first message.

The original #52372 case (a real concurrent connect during the metadata fetch) is preserved because a real connect attaches ws synchronously before the fetch resolves.

What the fix does

Restrict hasGatewaySocketStarted to a non-null ws. A stale isConnecting flag no longer suppresses normal gateway registration.

Tests

Updated provider.proxy.test.ts: the existing external-connect race regression now covers two branches. The ws branch still expects super.registerClient NOT to fire (#52372 behavior preserved). The isConnecting branch flips to expect super.registerClient to fire exactly once — that's the corrected behavior for #78104.

Real behavior proof

Unit test only. Local vitest invocation for extensions/discord/* fails before any test by an unrelated missing @openclaw/fs-safe/config import in src/infra/fs-safe-defaults.ts (known infra gap noted on several recent PRs in this area). The behavior change is single-branch and exercised by the inverted isConnecting case in the existing race test, which previously asserted the current bug.

Changed files

extensions/discord/src/monitor/gateway-plugin.ts (modified, +6/-1)
extensions/discord/src/monitor/provider.proxy.test.ts (modified, +5/-1)

Code Example

{
  "channels": {
    "discord": {
      "enabled": true,
      "token": "<redacted>",
      "groupPolicy": "allowlist",
      "dmPolicy": "allowlist",
      "allowFrom": ["<user-id>"],
      "guilds": {
        "<guild-id>": { "requireMention": false, "users": ["<user-id>"] }
      },
      "autoPresence": { "enabled": true },
      "healthMonitor": { "enabled": true },
      "heartbeat": { "useIndicator": true, "showOk": true, "showAlerts": true }
    }
  }
}

---

2026-05-05T17:23:48 channels/discord  [default] Discord bot probe resolved @clayton-agent
2026-05-05T17:23:48 channels/discord  [default] Discord Message Content Intent is limited; bots under 100 servers can use it without verification.
2026-05-05T17:23:49 channels/discord  discord client initialized as <bot-id>; awaiting gateway readiness
2026-05-05T17:23:51 fetch-timeout     WARN  url=https://discord.com/api/v10/users/@me timeoutMs=2500 elapsedMs=2501 — fetch timeout reached; aborting operation
2026-05-05T17:26:21 channels/discord  [default] Discord bot probe resolved @clayton-agent
2026-05-05T17:26:21 channels/discord  discord client initialized as <bot-id>; awaiting gateway readiness

(no "ready" event, no shard connect, no error follow-up)


Restart sequence (config hot reload + explicit restart):


2026-05-05T16:57:08 gateway/reload    config change detected (channels.discord.healthMonitor, channels.discord.heartbeat)
2026-05-05T16:57:08 gateway/channels  restarting discord channel
2026-05-05T16:57:52 gateway/channels  restarting discord channel  (heartbeat.showOk/showAlerts hot reload)
2026-05-05T16:58:17 gateway           http server listening (10 plugins; discord enabled)
2026-05-05T17:26:21 channels/discord  discord client initialized; awaiting gateway readiness  (after explicit gateway restart)


Independent host-side verification (same host, today):

- `curl https://discord.com/api/v10/gateway` → HTTP 200
- Standalone Node `ws` client to `wss://gateway.discord.gg/?v=10&encoding=json` → opens, HELLO frame received
- `curl -H "Authorization: Bot <token>" https://discord.com/api/v10/users/@me` → HTTP 200

Host network path to Discord gateway is healthy. The plugin's WS lifecycle still never reaches `ready` from inside the long-lived gateway process.

Suspected cause (carried forward from the 2026-05-04 writeup, not re-verified against 2026.5.4 source):


// @openclaw/discord OpenClawGatewayPlugin.registerClient
registration.catch(() => {});  // swallows all registration rejections silently
// + hasGatewaySocketStarted short-circuit when isConnecting=true was left over from an incomplete prior registration,
//   so super.registerClient(client) -> connect(false) is never invoked.


NODE_DEBUG=undici,http,tls trace from the prior report showed the gateway process opening REST connections to `discord.com` (HTTP 200 on `/users/@me` and `/oauth2/applications/@me`) and zero WebSocket activity to `gateway.discord.gg`. We did not re-instrument on 2026.5.4 because the external symptom is identical.

RAW_BUFFERClick to expand / collapse

Bug type

Regression (worked before, now fails)

Beta release blocker

Summary

Steps to reproduce

macOS 26.3.1 (Darwin 25.3.0 arm64), Node 22.22.0.
openclaw update 2026.5.3-1 → 2026.5.4.
openclaw plugins update @openclaw/[email protected] (was 2026.5.3-beta.1).
openclaw gateway restart.
Send a message in webchat that triggers a reply mirrored to Discord. First reply lands. Subsequent replies are silently dropped — no error surfaced to user, no error in logs.
Gateway log terminates the Discord init sequence with discord client initialized; awaiting gateway readiness and no follow-up ready event.

Expected behavior

Discord client should complete gateway readiness and deliver outbound messages reliably, matching pre-2026.5.3 behavior. The 2026.5.4 GA pair (peer dep openclaw>=2026.5.4 matches) was expected to resolve the prior 2026-05-04 silent-hang regression that was reproduced against @openclaw/discord 2026.5.2 / 2026.5.3 / 2026.5.3-beta.1 / 2026.5.3-beta.4.

Actual behavior

After every gateway start or channel hot reload, the Discord plugin logs the bot probe + intent + client init lines, then halts at discord client initialized; awaiting gateway readiness. No ready, no shard connect, no error log line. ~2.7s later, fetchWithTimeout warns against https://discord.com/api/v10/users/@me (timeoutMs=2500 elapsedMs=2501; fetch timeout reached; aborting operation). Outbound replies the agent emits are silently dropped after the first message post-restart. Inbound Discord messages still route to the agent and create sessions normally.

This matches the failure mode in the prior report: REST works once, the persistent gateway WebSocket lifecycle never reaches ready, and the suspected registration.catch(() => {}) swallow in OpenClawGatewayPlugin.registerClient continues to hide the underlying error.

OpenClaw version

2026.5.4

Operating system

macOS 26.3.1 (Darwin 25.3.0 arm64)

Install method

npm global (/opt/homebrew/lib/node_modules/openclaw); plugin installed via openclaw plugins update @openclaw/[email protected]

Model

anthropic/claude-opus-4-7 (channel-side issue; model not relevant)

Provider / routing chain

openclaw → discord.com (channel client; bot in 1 guild, all gateway intents granted)

Additional provider/model setup details

Discord channel config (redacted):

{
  "channels": {
    "discord": {
      "enabled": true,
      "token": "<redacted>",
      "groupPolicy": "allowlist",
      "dmPolicy": "allowlist",
      "allowFrom": ["<user-id>"],
      "guilds": {
        "<guild-id>": { "requireMention": false, "users": ["<user-id>"] }
      },
      "autoPresence": { "enabled": true },
      "healthMonitor": { "enabled": true },
      "heartbeat": { "useIndicator": true, "showOk": true, "showAlerts": true }
    }
  }
}

Plugin: @openclaw/[email protected] GA, peer dep openclaw>=2026.5.4 (matches). Workaround: set channels.discord.enabled=false and fall back to webchat/Telegram.

Logs, screenshots, and evidence

2026-05-05T17:23:48 channels/discord  [default] Discord bot probe resolved @clayton-agent
2026-05-05T17:23:48 channels/discord  [default] Discord Message Content Intent is limited; bots under 100 servers can use it without verification.
2026-05-05T17:23:49 channels/discord  discord client initialized as <bot-id>; awaiting gateway readiness
2026-05-05T17:23:51 fetch-timeout     WARN  url=https://discord.com/api/v10/users/@me timeoutMs=2500 elapsedMs=2501 — fetch timeout reached; aborting operation
2026-05-05T17:26:21 channels/discord  [default] Discord bot probe resolved @clayton-agent
2026-05-05T17:26:21 channels/discord  discord client initialized as <bot-id>; awaiting gateway readiness

(no "ready" event, no shard connect, no error follow-up)


Restart sequence (config hot reload + explicit restart):


2026-05-05T16:57:08 gateway/reload    config change detected (channels.discord.healthMonitor, channels.discord.heartbeat)
2026-05-05T16:57:08 gateway/channels  restarting discord channel
2026-05-05T16:57:52 gateway/channels  restarting discord channel  (heartbeat.showOk/showAlerts hot reload)
2026-05-05T16:58:17 gateway           http server listening (10 plugins; discord enabled)
2026-05-05T17:26:21 channels/discord  discord client initialized; awaiting gateway readiness  (after explicit gateway restart)


Independent host-side verification (same host, today):

- `curl https://discord.com/api/v10/gateway` → HTTP 200
- Standalone Node `ws` client to `wss://gateway.discord.gg/?v=10&encoding=json` → opens, HELLO frame received
- `curl -H "Authorization: Bot <token>" https://discord.com/api/v10/users/@me` → HTTP 200

Host network path to Discord gateway is healthy. The plugin's WS lifecycle still never reaches `ready` from inside the long-lived gateway process.

Suspected cause (carried forward from the 2026-05-04 writeup, not re-verified against 2026.5.4 source):


// @openclaw/discord OpenClawGatewayPlugin.registerClient
registration.catch(() => {});  // swallows all registration rejections silently
// + hasGatewaySocketStarted short-circuit when isConnecting=true was left over from an incomplete prior registration,
//   so super.registerClient(client) -> connect(false) is never invoked.


NODE_DEBUG=undici,http,tls trace from the prior report showed the gateway process opening REST connections to `discord.com` (HTTP 200 on `/users/@me` and `/oauth2/applications/@me`) and zero WebSocket activity to `gateway.discord.gg`. We did not re-instrument on 2026.5.4 because the external symptom is identical.

Impact and severity

Affected: Discord channel on macOS 26.3.1 with @openclaw/[email protected] GA + [email protected] GA. Telegram, iMessage, and webchat on the same gateway process are unaffected.
Severity: High — blocks Discord as a working agent channel. Outbound replies look "sent" to the agent (no error surfaced) but never arrive in Discord. Invisible failures are worse than hard errors.
Frequency: Always reproducible. 100% of restarts on this host since 2026-05-04 across @openclaw/discord 2026.5.2 / 2026.5.3 / 2026.5.3-beta.1 / 2026.5.3-beta.4 / 2026.5.4.
Consequence: Discord channel unusable for agent-driven conversation. One-shot openclaw message send --channel discord ... from a separate CLI process still works (confirmed via a LaunchAgent yesterday), so REST delivery from short-lived processes is fine; only the long-lived gateway client's WS lifecycle is broken.

Additional information

Last known good plugin version: unknown on this host — bug was first observed on 2026-05-04 immediately after a clean install on 2026.5.3-1, and reproduces on every plugin version tried since.
First known bad version: @openclaw/[email protected] (also has a separate missing-dist/ packaging issue).
@openclaw/[email protected] separate bug (already in the prior report): imports formatChannelProgressDraftLineForEntry from openclaw/plugin-sdk/channel-streaming, which does not exist in 2026.5.3-1. Prevents outbound delivery entirely with a SyntaxError. Not what we're hitting on GA — flagged here so peer compatibility can be bounded properly upstream.
Workaround applied today: disabled channels.discord.enabled on this host and restarted the gateway. Falling back to webchat/Telegram until the WS readiness path is fixed.
Local writeup with NODE_DEBUG output and line-level plugin pointers is available; happy to attach on request.

extent analysis

TL;DR

The Discord channel issue can be temporarily worked around by setting channels.discord.enabled=false and falling back to webchat or Telegram.

Guidance

Verify the Discord plugin configuration and ensure that the token and guild settings are correct.
Check the gateway logs for any error messages that may indicate the cause of the issue, such as the fetchWithTimeout warning.
Investigate the suspected cause of the issue, which is the registration.catch(() => {}) line in the OpenClawGatewayPlugin.registerClient method, and consider modifying it to properly handle registration rejections.
Test the workaround by disabling the Discord channel and restarting the gateway to ensure that the issue is resolved.

Example

No code snippet is provided as the issue is related to a specific plugin and configuration.

Notes

The issue seems to be specific to the @openclaw/discord plugin and the openclaw gateway, and may be related to a regression introduced in a recent version. The workaround provided may not be a permanent solution and further investigation is needed to resolve the issue.

Recommendation

Apply the workaround by setting channels.discord.enabled=false and falling back to webchat or Telegram until the issue is properly resolved. This will allow for continued use of the gateway while the Discord channel issue is being investigated and fixed.

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?

FAQ

Expected behavior

#api #model download #tokenizer error #prompt formatting #chain error

Still need to ship something?

×6

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

openclaw - ✅(Solved) Fix [Bug]: Discord channel hangs on "awaiting gateway readiness" after upgrade to 2026.5.4 [3 pull requests, 2 comments, 3 participants]

Recommended Tools

GitHub issue graph ai analysis

Error Message

Root Cause

Fix Action

Fix / Workaround

PR fix notes

PR #78132: fix: avoid stalled Discord gateway registration

Description (problem / solution / changelog)

Summary

Tests

Changed files

PR #19: fix(discord): clear stale isConnecting state before gateway re-registration

Description (problem / solution / changelog)

Summary

Changes

Test plan

Changed files

PR #78227: fix(discord): treat bare isConnecting=true as stale, not started gateway

Description (problem / solution / changelog)

Root cause

What the fix does

Tests

Real behavior proof

Changed files

Code Example

Bug type

Beta release blocker

Summary

Steps to reproduce

Expected behavior

Actual behavior

OpenClaw version

Operating system

Install method

Model

Provider / routing chain

Additional provider/model setup details

Logs, screenshots, and evidence

Impact and severity

Additional information

extent analysis

TL;DR

Guidance

Example

Notes

Recommendation

FAQ

Expected behavior

Still need to ship something?

RELATED_DISCOVERY

TRENDING