After `[discord] client initialized as ...`, within ~5 seconds: ``` [discord] logged in to discord as ( ) ``` And inbound `MESSAGE_CREATE` events should be delivered to the agent.

openclaw - ✅(Solved) Fix [Bug]: Discord gateway hang at 'awaiting gateway readiness' still reproduces on 2026.5.3-1 (macOS) — six closed dups, raw-ws test isolates failure to Carbon Client lifecycle [3 pull requests, 21 comments, 6 participants]

openclaw2026-05-05 03:54:54

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#77668•Fetched 2026-05-06 06:23:16

View on GitHub

Comments

Participants

Timeline

Reactions

Author

Participants

Timeline (top)

commented ×21cross-referenced ×8mentioned ×6subscribed ×6

On macOS, the Discord gateway plugin (Carbon) silently hangs at client initialized as <id>; awaiting gateway readiness after restart, never reaching READY, with no timeout/error event ever fired. A raw ws connection from the same Node binary, same node_modules/ws, same machine, same bot token completes the WS handshake to gateway.discord.gg in <1 second — proving the failure is purely inside Carbon's Client constructor → registerClient async flow, not the network/token/Discord. Still reproduces on 2026.5.3-1 despite #56492 / #57075 / #58290 / #59820 / #70841 / #63223 having been closed as duplicates over the past two months.

Error Message

node -e ' const WebSocket = require("/path/to/openclaw/node_modules/ws"); const ws = new WebSocket("wss://gateway.discord.gg/?v=10&encoding=json"); ws.on("open", () => console.log("OPEN")); ws.on("message", (d) => { console.log("MSG:", d.toString().slice(0, 200)); ws.close(); process.exit(0); }); ws.on("error", (e) => { console.log("ERROR:", e.message); process.exit(2); }); '

Root Cause

Additional provider/model setup details

Single bot account, single guild, single allowed user
commands.native: false and commands.nativeSkills: false (eliminates #60559 slash-deploy contribution to event-loop blocking)
agentRuntime.fallback: "none" (eliminates API fallback masking the real error)
Plist EnvironmentVariables.NSAppSleepDisabled: YES, ProcessType: Interactive (rules out App Nap throttling per Apple TN3433)
3 plugins loaded: anthropic, discord, memory-core
Carbon library: @buape/carbon (bundled in openclaw dist; couldn't easily extract version because plugin runtime deps are now externalized to @openclaw/discord per #76405 / #77483)

Fix Action

Fix / Workaround

Regression timeline (all closed as duplicates of root-cause issue #56492 which itself is closed):

Last known good: pre-2026.3.22 (first carbon-based release)
v2026.3.22+: hang reported by multiple users (#53132, #57075, #58290)
v2026.4.1: still hanging (#59820)
v2026.4.2: --verbose flag found to be a workaround due to event-loop scheduling side-effect (#60559)
v2026.4.5: missing READY log line introduced (#63223 Problem B) making the bug invisible to log-based monitoring
v2026.4.21: ~80% failure rate on macOS confirmed (#70841)
v2026.5.3-1 (this report): still reproduces with same symptoms, same root-cause behavior

Workarounds that work some of the time:

launchctl bootout + 60s drain + launchctl bootstrap (≈10–50% success on this host)
Full Mac reboot (≈90% success per anecdotal reports in closed issues; not yet verified on this host)
--verbose flag (#60559 — appears to side-step the race via additional event-loop microtasks; cannot be set on macOS launchd plists without rewriting ProgramArguments)

Workarounds that do NOT work on 2026.5.3-1:

kill -9 $GATEWAY_PID followed by launchd respawn
launchctl kickstart -k (leaves stale TCP sockets attached)
openclaw doctor --fix (does not touch the discord plugin lifecycle)

PR fix notes

PR #77956: fix(discord): prevent false heartbeat ACK timeout on first interval tick

Repository: openclaw/openclaw
Author: NikolaFC
State: closed | merged: False
Link: https://github.com/openclaw/openclaw/pull/77956

Description (problem / solution / changelog)

Problem

The Discord gateway hangs at "awaiting gateway readiness" intermittently (reported in #77668, also #52372, #53039, #68213).

After investigation, I found a race condition in GatewayHeartbeatTimers.start() (extensions/discord/src/internal/gateway-lifecycle.ts):

The first heartbeat uses a random delay (intervalMs * random())
The ACK timeout check uses a fixed interval (setInterval(..., intervalMs)) that starts from start() time

When random() ≈ 1.0:

First heartbeat fires at ~T0 + intervalMs
First setInterval tick fires at T0 + intervalMs
The ACK hasn't had time to arrive → false "Gateway heartbeat ACK timeout" → needless reconnect

This creates a reconnect loop that makes Discord appear to hang at "awaiting gateway readiness".

Fix

Replace setInterval with recursive setTimeout so the ACK check always runs a full intervalMs AFTER the preceding heartbeat was sent:

Old:  setInterval(checkAckOrSend, intervalMs)   ← starts from T0
New:  setTimeout(checkAckThenScheduleNext, intervalMs)  ← starts from last heartbeat

Real Behavior Proof

Behavior or issue addressed: Discord gateway heartbeat ACK timeout race condition causing false reconnect loop (#77668)

Real environment tested: OpenClaw 2026.5.5 (43dcdcd) on WSL2 Ubuntu 22.04, Node.js v22.22.0, Discord bot 1483184501986164748

Exact steps or command run after this patch:

pnpm build in hackable-src (commit 43dcdcd9)
Patched ~/.openclaw/npm/node_modules/@openclaw/discord/dist/provider-CnLt-Y4Z.js with recursive setTimeout heartbeat logic
systemctl --user restart openclaw-gateway
Monitored journalctl --user -u openclaw-gateway -f for 2+ minutes

Evidence after fix:

19:32:32 [discord] client initialized as 1483184501986164748; awaiting gateway readiness
19:32:32 WebSocket OPEN event fired
19:32:33 message: op=0 t=READY           ← Discord connected
19:32:34 message: op=11 t=null           ← heartbeat ACK received
19:33:15 message: op=11 t=null           ← second heartbeat ACK, stable

Observed result after fix: Zero "heartbeat ACK timeout" log entries. Discord stays connected with regular heartbeat ACKs. Gateway running stable for 2+ minutes with no reconnect cycles. Previously would cycle through connect → false ACK timeout → reconnect indefinitely.

What was not tested: Long-running (24h+) stability; multi-guild load; Windows native environment.

Tests

Added gateway-lifecycle.test.ts with 4 tests:

No false timeout when random ≈ 1.0 — the core bug
Genuine ACK timeout still fires — when heartbeat is truly not acked
Regular heartbeat intervals — timing correctness
stop() cancels all timers — cleanup

All existing Discord gateway tests (20 in gateway.test.ts, 15 in gateway-plugin.test.ts) still pass.

Fixes #77668
Related to #53039 (registerClient race — already fixed in current code)
Related to #68213 (heartbeat ACK as liveness signal — different approach)

Changed files

CHANGELOG.md (modified, +1/-0)
extensions/discord/src/internal/gateway-lifecycle.test.ts (added, +147/-0)
extensions/discord/src/internal/gateway-lifecycle.ts (modified, +32/-10)

PR #78087: fix: schedule discord heartbeat checks after sends

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

Description (problem / solution / changelog)

Summary

Fixes the Discord gateway heartbeat scheduler so ACK timeout checks are measured from the actual heartbeat send time, not from the HELLO-time fixed interval.

The previous scheduler randomized the first heartbeat but started a fixed interval immediately. If the first heartbeat fired late in that interval — or the event loop was delayed — the next interval tick could check lastHeartbeatAck too soon after the send and trigger a false Gateway heartbeat ACK timeout/reconnect cycle while the Discord channel was still awaiting readiness.

Changes

Replace the fixed heartbeat interval with a chained timeout cycle.
Keep randomized first heartbeat behavior.
After each heartbeat send, schedule the ACK check one full heartbeat interval later.
If ACKed, send the next heartbeat and schedule the next check from that send.
Keep reconnect cleanup clearing both first-heartbeat and heartbeat-cycle timers.
Add dedicated regression coverage for late randomized first heartbeat, genuine ACK timeout, ACKed heartbeat cycles, and timer cleanup.
Add a changelog entry crediting both contributors.

Real Behavior Proof

Behavior or issue addressed: Discord gateway heartbeat ACK timeout race causing false reconnect loops and intermittent awaiting gateway readiness hangs (#77668).

Real environment tested: OpenClaw 2026.5.5 from commit 43dcdcd9 on WSL2 Ubuntu 22.04, Node.js v22.22.0, Discord bot runtime.

Exact steps or command run after this patch:

pnpm build in the OpenClaw source checkout.
Patched the installed @openclaw/discord runtime bundle with the recursive timeout heartbeat logic.
systemctl --user restart openclaw-gateway.
Monitored journalctl --user -u openclaw-gateway -f for 2+ minutes.

Evidence after fix: Runtime log excerpt from the real Discord gateway run:

19:32:32 [discord] client initialized as 1483184501986164748; awaiting gateway readiness
19:32:32 WebSocket OPEN event fired
19:32:33 message: op=0 t=READY
19:32:34 message: op=11 t=null
19:33:15 message: op=11 t=null

Observed result after fix: Zero Gateway heartbeat ACK timeout entries; Discord reached READY and stayed connected with repeated heartbeat ACKs instead of reconnecting.

What was not tested: Long-running 24h+ stability, multi-guild load, and Windows native runtime were not covered by this after-fix run. The original #77668 reporter offered to rerun 5 macOS launchd restart cycles once this lands.

Testing

pnpm exec oxfmt --write --threads=1 CHANGELOG.md extensions/discord/src/internal/gateway-lifecycle.ts extensions/discord/src/internal/gateway-lifecycle.test.ts extensions/discord/src/internal/gateway.test.ts — passed.
pnpm test extensions/discord/src/internal/gateway-lifecycle.test.ts extensions/discord/src/internal/gateway.test.ts — passed, 2 files / 24 tests.
pnpm exec oxfmt --check --threads=1 CHANGELOG.md extensions/discord/src/internal/gateway-lifecycle.ts extensions/discord/src/internal/gateway-lifecycle.test.ts extensions/discord/src/internal/gateway.test.ts — passed.
git diff --check — passed.

Fixes #77668 Supersedes #77956

Changed files

CHANGELOG.md (modified, +1/-0)
extensions/discord/src/internal/gateway-lifecycle.test.ts (added, +114/-0)
extensions/discord/src/internal/gateway-lifecycle.ts (modified, +24/-10)

PR #78235: Fix Discord gateway heartbeat ACK timing

Repository: openclaw/openclaw
Author: wena369
State: closed | merged: False
Link: https://github.com/openclaw/openclaw/pull/78235

Description (problem / solution / changelog)

Summary

This updates Discord gateway heartbeat scheduling so ACK timeout checks run one full heartbeat interval after each heartbeat send, instead of using a fixed interval that can fire shortly after the randomized first heartbeat.

Validation

Ran extensions/discord/src/internal/gateway.test.ts
21 tests passed

Notes

This should help avoid false Gateway heartbeat ACK timeout errors after heartbeats are being scheduled. In my Windows runtime investigation, the production instability also appeared correlated with gateway event-loop starvation from deferred/missed cron jobs during startup, so this patch may not address every awaiting gateway readiness failure mode.

Real behavior proof

behavior: Discord gateway heartbeat ACK timing after applying this patch.

environment: Windows host running the locally patched OpenClaw build from this branch.

steps: Applied this branch locally, built OpenClaw, started the patched gateway from O:/openclaw/dist, waited for startup, then ran openclaw gateway status --deep --require-rpc.

evidence: Copied live output from the patched local runtime showed file:///O:/openclaw/dist/subsystem-DtIxQOmd.js, http server listening (2 plugins: discord, memory-core; 66.2s), gateway ready, heartbeat: started, discord channels resolved, discord channel users resolved, and status 3402ms. Gateway status from the same host showed Runtime: running, Read probe: ok, Capability: admin-capable, and Listening: 127.0.0.1:18789.

observedResult: The patched local gateway stayed running and responded to RPC health checks. No new Gateway heartbeat ACK timeout was observed in the checked runtime window.

notTested: This does not prove the patch fixes every awaiting gateway readiness failure mode. My earlier Windows incident also had a separate cron/event-loop starvation component.

Changed files

extensions/discord/src/internal/gateway-lifecycle.ts (modified, +19/-13)
extensions/discord/src/internal/gateway.test.ts (modified, +31/-0)

Code Example

[discord] [default] starting provider (@K2)
[discord] channels resolved: <guild_id> (guild:K2; aliases:guild:<guild_id>)
[discord] users resolved: <user_id>
[discord] channel users resolved: <user_id>
[discord] client initialized as <bot_id>; awaiting gateway readiness
                                                ^^^ silent forever — no further [discord] events

---

node -e '
const WebSocket = require("/path/to/openclaw/node_modules/ws");
const ws = new WebSocket("wss://gateway.discord.gg/?v=10&encoding=json");
ws.on("open",    () => console.log("OPEN"));
ws.on("message", (d) => { console.log("MSG:", d.toString().slice(0, 200)); ws.close(); process.exit(0); });
ws.on("error",   (e) => { console.log("ERROR:", e.message); process.exit(2); });
'

---

OPEN: WebSocket opened to Discord
MSG: {"t":null,"s":null,"op":10,"d":{"heartbeat_interval":41250,"_trace":[...]}}

---

[discord] logged in to discord as <bot_id> (<username>)

---

node 87471 ... TCP 192.168.1.178:51830->162.159.136.234:https (ESTABLISHED)
  node 87471 ... TCP 192.168.1.178:54742->162.159.137.232:https (ESTABLISHED)

---

2026-05-04T20:09:42.638-07:00 [discord] users resolved: <user_id>
2026-05-04T20:09:42.639-07:00 [discord] channel users resolved: <user_id>
2026-05-04T20:09:43.106-07:00 [discord] client initialized as <bot_id>; awaiting gateway readiness
[silence — no further discord events for 30+ minutes]
2026-05-04T20:12:20.690-07:00 [gateway] http server listening (3 plugins: anthropic, discord, memory-core; 3.8s)
2026-05-04T20:12:22.636-07:00 [discord] [default] starting provider (@K2)
2026-05-04T20:12:23.497-07:00 [discord] channels resolved: <guild_id>
2026-05-04T20:12:23.672-07:00 [discord] client initialized as <bot_id>; awaiting gateway readiness
[silence — same hang on second bootout/bootstrap cycle]

RAW_BUFFERClick to expand / collapse

Bug type

Regression (worked before, now fails)

Beta release blocker

Summary

Steps to reproduce

Install OpenClaw 2026.5.3-1 on macOS via npm global, run as a ~/Library/LaunchAgents/ai.openclaw.gateway.plist LaunchAgent.
Configure a single Discord bot account, single guild, with commands.native: false and commands.nativeSkills: false (rules out the slash-deploy CPU spike from #60559).
launchctl bootout "gui/$(id -u)/ai.openclaw.gateway" → wait 60s → launchctl bootstrap …
tail -f ~/.openclaw/logs/gateway.log | grep '\[discord\]'

Observed (every restart over the past 36+ hours, ~10 attempts):

[discord] [default] starting provider (@K2)
[discord] channels resolved: <guild_id> (guild:K2; aliases:guild:<guild_id>)
[discord] users resolved: <user_id>
[discord] channel users resolved: <user_id>
[discord] client initialized as <bot_id>; awaiting gateway readiness
                                                ^^^ silent forever — no further [discord] events

Smoking-gun isolation test — same machine, same token, same ws library bundled with OpenClaw:

node -e '
const WebSocket = require("/path/to/openclaw/node_modules/ws");
const ws = new WebSocket("wss://gateway.discord.gg/?v=10&encoding=json");
ws.on("open",    () => console.log("OPEN"));
ws.on("message", (d) => { console.log("MSG:", d.toString().slice(0, 200)); ws.close(); process.exit(0); });
ws.on("error",   (e) => { console.log("ERROR:", e.message); process.exit(2); });
'

Output (every time, in <1s):

OPEN: WebSocket opened to Discord
MSG: {"t":null,"s":null,"op":10,"d":{"heartbeat_interval":41250,"_trace":[...]}}

So Discord IS sending HELLO. Carbon's GatewayPlugin just never processes it — the 'open' and 'message' handlers either aren't registered before the frame arrives, or registration completes after the frame is already buffered/dropped. This matches the un-awaited-registerClient race documented in #56492 root-cause.

Expected behavior

After [discord] client initialized as ..., within ~5 seconds:

[discord] logged in to discord as <bot_id> (<username>)

And inbound MESSAGE_CREATE events should be delivered to the agent.

Actual behavior

No logged in to discord event ever logged. (Even when the bot IS sometimes alive — see #63223 Problem B about the missing READY log.)
No 15-second gateway was not ready timeout fires. (The ?? true nullish-default in waitForGatewayReady returns ready=true from a hung promise — same as #70841.)
Inbound Discord messages never reach the agent (silently dropped).
Outbound REST works fine (curl Authorization: Bot $TOKEN https://discord.com/api/v10/users/@me → 200).
lsof -p <gateway_pid> -i -n shows multiple stacked ESTABLISHED TCP connections from the gateway to Discord IPs — Carbon opens new sockets without closing the wedged ones. Snapshot from this session:
```
node 87471 ... TCP 192.168.1.178:51830->162.159.136.234:https (ESTABLISHED)
node 87471 ... TCP 192.168.1.178:54742->162.159.137.232:https (ESTABLISHED)
```

OpenClaw version

2026.5.3-1

Operating system

macOS 26.3.1 (build 25D771280a, Apple Silicon)

Install method

npm global (npm install -g openclaw), launched by ~/Library/LaunchAgents/ai.openclaw.gateway.plist

Model

anthropic/claude-opus-4-7 (via agentRuntime.id: "claude-cli" subprocess to local Claude Code CLI)

Provider / routing chain

discord ← openclaw-gateway → claude-cli subprocess → claude.ai OAuth (overage disabled at org level, irrelevant to this bug)

Additional provider/model setup details

Single bot account, single guild, single allowed user
commands.native: false and commands.nativeSkills: false (eliminates #60559 slash-deploy contribution to event-loop blocking)
agentRuntime.fallback: "none" (eliminates API fallback masking the real error)
Plist EnvironmentVariables.NSAppSleepDisabled: YES, ProcessType: Interactive (rules out App Nap throttling per Apple TN3433)
3 plugins loaded: anthropic, discord, memory-core
Carbon library: @buape/carbon (bundled in openclaw dist; couldn't easily extract version because plugin runtime deps are now externalized to @openclaw/discord per #76405 / #77483)

Logs, screenshots, and evidence

2026-05-04T20:09:42.638-07:00 [discord] users resolved: <user_id>
2026-05-04T20:09:42.639-07:00 [discord] channel users resolved: <user_id>
2026-05-04T20:09:43.106-07:00 [discord] client initialized as <bot_id>; awaiting gateway readiness
[silence — no further discord events for 30+ minutes]
2026-05-04T20:12:20.690-07:00 [gateway] http server listening (3 plugins: anthropic, discord, memory-core; 3.8s)
2026-05-04T20:12:22.636-07:00 [discord] [default] starting provider (@K2)
2026-05-04T20:12:23.497-07:00 [discord] channels resolved: <guild_id>
2026-05-04T20:12:23.672-07:00 [discord] client initialized as <bot_id>; awaiting gateway readiness
[silence — same hang on second bootout/bootstrap cycle]

Last successful login over the past 36 hours: 2026-05-03 09:57:36 (one success across ~10 restart attempts on this host).

Discord session_start_limit on the affected bot at the time of writing: remaining: 960/1000, resets in 588 min — confirming Discord-side identify quota is not the cause.

Impact and severity

Affected: any single-bot Discord deployment on macOS launchd (this report); per #70841 the same host saw ~80% failure rate on 4.21
Severity: High — Discord channel becomes silently non-functional. Outbound REST still works so the bot appears "online" to humans, but inbound messages are dropped without any user-facing error
Frequency: ~90% of restarts on this host across 36+ hours
Consequence: End users perceive the bot as ignoring messages. No log signal that anything is wrong (no error, no timeout). Watchdogs that grep for "logged in to discord" misfire because that line was suppressed in 2026.4.5 (per #63223 Problem B), so even healthy boots can no longer be distinguished from wedged ones via logs alone.

Additional information

Regression timeline (all closed as duplicates of root-cause issue #56492 which itself is closed):

Last known good: pre-2026.3.22 (first carbon-based release)
v2026.3.22+: hang reported by multiple users (#53132, #57075, #58290)
v2026.4.1: still hanging (#59820)
v2026.4.2: --verbose flag found to be a workaround due to event-loop scheduling side-effect (#60559)
v2026.4.5: missing READY log line introduced (#63223 Problem B) making the bug invisible to log-based monitoring
v2026.4.21: ~80% failure rate on macOS confirmed (#70841)
v2026.5.3-1 (this report): still reproduces with same symptoms, same root-cause behavior

Workarounds that work some of the time:

launchctl bootout + 60s drain + launchctl bootstrap (≈10–50% success on this host)
Full Mac reboot (≈90% success per anecdotal reports in closed issues; not yet verified on this host)
--verbose flag (#60559 — appears to side-step the race via additional event-loop microtasks; cannot be set on macOS launchd plists without rewriting ProgramArguments)

Workarounds that do NOT work on 2026.5.3-1:

kill -9 $GATEWAY_PID followed by launchd respawn
launchctl kickstart -k (leaves stale TCP sockets attached)
openclaw doctor --fix (does not touch the discord plugin lifecycle)

Suggested fix priority order:

Make Client.registerClient(plugin) async-aware in @buape/carbon so the constructor's plugin loop awaits the promise. Per #56492 the constructor currently does for (const p of plugins) { p.registerClient?.(this); } with no await. This is the upstream fix.
In OpenClaw's discord provider, after new Client(...), explicitly await client.getPlugin('gateway')?.registerClient?.(client) so the WebSocket connection is guaranteed to be established before lifecycleGateway.isConnected is polled. This is the OpenClaw-side fix that doesn't require waiting on Carbon upstream.
Restore the [discord] logged in to discord as ... log line even when the underlying event flow has been refactored. Watchdogs and operators rely on this for liveness. Currently it is silently dropped per #63223.
Replace the ?? true nullish-default in the waitForGatewayReady guard with ?? false (or surface the actual hung-promise state) so the documented 15-second timeout actually fires. Per #70841 this is currently masking the failure.

I am happy to test patches on this affected macOS host — the bug reproduces deterministically here.

Cross-references: #56492 (root cause, closed dup) · #57075 (single-account, closed dup) · #58290 (closed dup) · #59820 (closed dup) · #70841 (closed dup, macOS, ~80% rate) · #63223 (open, missing READY log) · #60559 (closed, --verbose workaround)

extent analysis

TL;DR

The most likely fix for the Discord gateway plugin hanging issue is to make the Client.registerClient(plugin) method async-aware in the @buape/carbon library or to explicitly await the registerClient promise in OpenClaw's discord provider.

Guidance

Verify that the issue is indeed caused by the Client.registerClient(plugin) method not being async-aware by checking the @buape/carbon library code.
Consider applying the suggested fix priority order:
1. Make Client.registerClient(plugin) async-aware in @buape/carbon.
2. Explicitly await client.getPlugin('gateway')?.registerClient?.(client) in OpenClaw's discord provider.
3. Restore the [discord] logged in to discord as ... log line.
4. Replace the ?? true nullish-default in the waitForGatewayReady guard with ?? false.
Test patches on the affected macOS host to verify the fix.

Example

No code snippet is provided as the issue requires changes to the @buape/carbon library or OpenClaw's discord provider.

Notes

The issue is a regression that has been reported in multiple versions of OpenClaw, and the suggested fixes are based on the analysis of the issue and the provided workarounds.

Recommendation

Apply the first suggested fix: Make Client.registerClient(plugin) async-aware in @buape/carbon, as it addresses the root cause of 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?

FAQ

Expected behavior

After [discord] client initialized as ..., within ~5 seconds:

[discord] logged in to discord as <bot_id> (<username>)

And inbound MESSAGE_CREATE events should be delivered to the agent.

#api #prompt template #agent execution #callback error #memory management

Still need to ship something?

×6

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

openclaw - ✅(Solved) Fix [Bug]: Discord gateway hang at 'awaiting gateway readiness' still reproduces on 2026.5.3-1 (macOS) — six closed dups, raw-ws test isolates failure to Carbon Client lifecycle [3 pull requests, 21 comments, 6 participants]

Recommended Tools

GitHub issue graph ai analysis

Error Message

Root Cause

Additional provider/model setup details

Fix Action

Fix / Workaround

PR fix notes

PR #77956: fix(discord): prevent false heartbeat ACK timeout on first interval tick

Description (problem / solution / changelog)

Problem

Fix

Real Behavior Proof

Tests

Related

Changed files

PR #78087: fix: schedule discord heartbeat checks after sends

Description (problem / solution / changelog)

Summary

Changes

Real Behavior Proof

Testing

Changed files

PR #78235: Fix Discord gateway heartbeat ACK timing

Description (problem / solution / changelog)

Summary

Validation

Notes

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