PR #54945: fix(discord): catch gateway emitter errors to prevent whole-gateway crash on WebSocket failure

• Repository: openclaw/openclaw
• Author: lyfuci
• State: open | merged: False
• Link: https://github.com/openclaw/openclaw/pull/54945

Description (problem / solution / changelog)

Summary

A transient Discord WebSocket disconnection (e.g. close code 1005) can crash the entire gateway process, taking down all channels (Feishu, WhatsApp, Telegram, etc.) — not just Discord.

Root Cause

In Node.js, if an EventEmitter emits "error" with no registered listener, it throws an unhandled error. This hits the global uncaughtException handler in src/index.ts which calls process.exit(1), killing the whole gateway.

The @buape/carbon GatewayPlugin can emit an "error" event (e.g. when maxAttempts is exhausted), and provider.lifecycle.ts had no listener on gatewayEmitter for that event — only a "debug" listener was registered.

Fix

Add an onGatewayEmitterError listener in extensions/discord/src/monitor/provider.lifecycle.ts that catches error events on the gateway emitter, logs them as warnings, and lets the existing lifecycle handler manage structured recovery (reconnect-exhausted → channel restart, fatal intents error → stop).

The listener is cleaned up in the finally block alongside the existing "debug" listener so there's no leak.

const onGatewayEmitterError = (error: unknown) => {
  runtime.warn?.(
    `discord: gateway emitter error (caught to prevent process crash): ${String(error)}`,
  );
};
gatewayEmitter?.on("error", onGatewayEmitterError);
// ... cleaned up in finally
gatewayEmitter?.off("error", onGatewayEmitterError);

Testing

pnpm test:extension discord: 51 test files, 476 tests — all passed ✅

AI Assistance

• AI-assisted (Claude Sonnet 4.6 via OpenClaw)
• Lightly tested — pnpm check + pnpm test:extension discord passed
• Full pnpm build && pnpm test not run (CI will validate)
• Code reviewed and understood by human author

Fixes #54894

Changed files

• extensions/discord/src/monitor/provider.lifecycle.ts (modified, +11/-0)

PR #54974: fix(discord): prevent gateway crash during health-monitor restart

• Repository: openclaw/openclaw
• Author: openperf
• State: closed | merged: False
• Link: https://github.com/openclaw/openclaw/pull/54974

Description (problem / solution / changelog)

Summary

— Discord health-monitor triggers uncaught exception crash loop, bringing down the entire gateway every ~35 minutes after upgrading from v2026.3.11 to v2026.3.24.

— Discord WebSocket reconnect failure crashes entire gateway

Root Cause

An uncaught exception occurred due to a timing issue during the channel teardown sequence:

1. In the onAbort handler, setting gateway.options.reconnect = { maxAttempts: 0 } and calling gateway.disconnect() synchronously triggered a Max reconnect attempts (0) reached error from @buape/carbon.
2. Because gatewaySupervisor.detachLifecycle() was previously only called in the finally block, the supervisor was still in the active phase when this synchronous error was emitted.
3. The error was routed to the lifecycle handler, treated as a fatal reconnect-exhausted event, and eventually rejected the wait promise.
4. The catch block in runDiscordGatewayLifecycle only swallowed disallowed-intents errors, so this reconnect error was re-thrown, causing an uncaught exception that crashed the entire gateway process.

Changes

extensions/discord/src/monitor/provider.lifecycle.ts

• Transitioned the supervisor to the teardown phase by calling params.gatewaySupervisor.detachLifecycle() before disconnecting the gateway in the onAbort handler. This ensures the synchronous reconnect error is safely suppressed by the supervisor's existing logLateTeardownEvent mechanism.
• Added a safety net in the catch block to swallow all errors when lifecycleStopping is true, preventing any residual reconnect errors from propagating as uncaught exceptions during an intentional shutdown.

Test Results

All existing Discord lifecycle and supervisor tests pass. The idempotency of detachLifecycle() ensures the repeated call in the finally block remains safe.

Changed files

• extensions/discord/src/monitor/provider.lifecycle.ts (modified, +15/-1)

PR #55000: fix(discord): prevent gateway crash on abort by fixing supervisor teardown ordering

• Repository: openclaw/openclaw
• Author: openperf
• State: open | merged: False
• Link: https://github.com/openclaw/openclaw/pull/55000

Description (problem / solution / changelog)

Summary

A transient Discord WebSocket disconnection (e.g. close code 1005) or an intentional health-monitor restart can trigger an uncaught Max reconnect attempts (0) exception that crashes the entire gateway process. This kills all channels (Feishu, WhatsApp, Telegram, etc.), not just Discord.

This PR fixes the root cause of these gateway crashes by correcting the supervisor phase transition ordering during an abort.

Fixes #54931 Fixes #54894

Root Cause

The gateway crash happens due to an error routing mismatch during teardown:

1. onAbort() sets maxAttempts to 0 and calls gateway.disconnect().
2. disconnect() synchronously triggers @buape/carbon's handleClose → handleReconnectionAttempt, which emits a Max reconnect attempts (0) error on the gateway emitter.
3. The gateway-supervisor is still in the active phase at this point, so it routes the error to the lifecycle handler instead of suppressing it.
4. The error surfaces as an uncaught exception, causing the entire gateway process to exit.

The supervisor already has the correct teardown suppression logic (it logs and swallows late errors during the teardown phase). The bug is simply that onAbort() never transitions the supervisor to the teardown phase before disconnecting.

Changes

1. Fix teardown ordering in onAbort()

Call params.gatewaySupervisor.detachLifecycle() before gateway.disconnect(). This ensures the supervisor enters the teardown phase and correctly suppresses the synchronous error emitted during disconnect.

2. Add lifecycleStopping safety net

In the catch block, when lifecycleStopping is already true, we no longer re-throw errors. This acts as a defense-in-depth guard for any edge case where an error might still escape during an intentional shutdown.

Test Results

• The extension-fast (extension-fast-discord, discord) CI check passes.
• Verified locally that triggering an abort correctly suppresses the disconnect error and allows the gateway to restart gracefully without crashing the main process.

Changed files

• extensions/discord/src/monitor/provider.lifecycle.ts (modified, +14/-1)