PR #55558: fix(discord): suppress expected reconnect-exhausted on stale-socket restart

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

Description (problem / solution / changelog)

Summary

• treat reconnect-exhausted as expected whenever Discord gateway reconnect has already been forced into maxAttempts=0 intentional shutdown/restart mode
• keep the lifecycle from surfacing the expected code 1005 reconnect exhaustion as an uncaught fatal error during stale-socket restarts
• update the lifecycle regression test to cover the queued-event ordering that previously crashed the gateway

Testing

• pnpm test -- extensions/discord/src/monitor/provider.lifecycle.test.ts (fails in this environment because node_modules is missing)
• pnpm install (fails in this environment due npm DNS/network error: EAI_AGAIN to registry.npmjs.org)

Closes #55554

Changed files

• extensions/discord/src/monitor/provider.lifecycle.test.ts (modified, +8/-8)
• extensions/discord/src/monitor/provider.lifecycle.ts (modified, +5/-6)

PR #55699: fix(discord): suppress expected reconnect-exhausted on stale-socket restart

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

Description (problem / solution / changelog)

Summary

• Problem: When the health-monitor triggers a stale-socket restart, it sets gateway.options.reconnect.maxAttempts = 0 then calls disconnect(). Carbon immediately emits "Max reconnect attempts (0) reached after code 1005", which lands in the supervisor's pending queue while the lifecycle is still awaiting an early step (e.g. execApprovalsHandler.start()).
• Why it matters: The previous guard checked lifecycleStopping, which is only set in the finally block — after drainPendingGatewayErrors() has already run. The queued event fell through to throw event.err, crashing the entire gateway process (~54s downtime per occurrence, recurring every ~35 minutes).
• What changed: Replaced the timing-sensitive lifecycleStopping check with isExpectedReconnectExhausted, which checks gateway.options.reconnect.maxAttempts === 0. This value is set synchronously before disconnect(), so it is reliably true at drain time regardless of async ordering. Added a regression test confirming that reconnect-exhausted with maxAttempts !== 0 (genuine Carbon retry exhaustion) still propagates as a fatal error.
• What did NOT change: No change to reconnect logic, health-monitor behavior, or any other lifecycle path.

Change Type (select all)

• Bug fix

Scope (select all touched areas)

• Gateway / orchestration
• Integrations

Linked Issue/PR

• Closes #55554
• This PR fixes a bug or regression

Root Cause / Regression History (if applicable)

• Root cause: lifecycleStopping is set in the finally block of runDiscordGatewayLifecycle, but drainPendingGatewayErrors() is called inside the try block — before finally ever runs. On a stale-socket restart, the reconnect-exhausted event is queued synchronously (Carbon emits in the same tick as disconnect()), so it is always drained before lifecycleStopping becomes true.
• Missing detection / guardrail: No test covered the queued-before-drain timing window.
• Prior context: The lifecycleStopping guard was added to handle intentional shutdowns, but did not account for the async ordering between drainPendingGatewayErrors and the finally block.
• Why this regressed now: The health-monitor stale-socket path sets maxAttempts=0 and disconnects — Carbon's error fires faster than the lifecycle flag advances.

Regression Test Plan (if applicable)

• Coverage level that should have caught this:
  • Unit test
• Target test: extensions/discord/src/monitor/provider.lifecycle.test.ts
• Scenario: queue a reconnect-exhausted event before abort fires; verify lifecycle resolves cleanly (not rejects) when maxAttempts=0; verify it still rejects when maxAttempts is not 0.
• Why this is the smallest reliable guardrail: directly exercises the drain-before-finally timing window without requiring real WebSocket infrastructure.

User-visible / Behavior Changes

Gateway no longer crashes on health-monitor stale-socket restarts. The restart proceeds silently (log at info level instead of an uncaught exception).

Diagram (if applicable)

Before:
[health-monitor abort] -> [maxAttempts=0, disconnect()] -> [Carbon emits error]
  -> [pending queue] -> [drainPendingGatewayErrors]
  -> lifecycleStopping=false -> throw event.err -> CRASH

After:
[health-monitor abort] -> [maxAttempts=0, disconnect()] -> [Carbon emits error]
  -> [pending queue] -> [drainPendingGatewayErrors]
  -> maxAttempts===0 -> log + return "stop" -> lifecycle resolves cleanly

Security Impact (required)

• New permissions/capabilities? No
• Secrets/tokens handling changed? No
• New/changed network calls? No
• Command/tool execution surface changed? No
• Data access scope changed? No

Repro + Verification

Environment

• OS: macOS (darwin arm64) / Windows 10 x64 (as reported in issue)
• Runtime: Node 24.14.1
• Integration/channel: Discord

Steps

1. Gateway running with Discord channel enabled
2. Health-monitor detects stale socket and triggers restart
3. WebSocket closes with code 1005

Expected

Gateway handles reconnect-exhausted gracefully, logs at info level, continues running.

Actual (before fix)

Uncaught exception: Error: Max reconnect attempts (0) reached after code 1005 — gateway process crashes.

Evidence

• Failing test before + passing after: repurposed existing test "does not suppress reconnect-exhausted already queued before shutdown" → now asserts resolves.toBeUndefined() and confirms the info log. Added "does not suppress reconnect-exhausted when maxAttempts is not 0" as the negative regression guard. All 22 tests pass.

Human Verification (required)

• Verified scenarios: lifecycle test suite (22/22), full discord extension test suite — all pass.
• Edge cases checked: maxAttempts undefined (default gateway options) still propagates as fatal; maxAttempts=0 with code 1005 resolves cleanly.
• What I did not verify: live Discord environment with actual stale-socket trigger (no Discord bot token available).

Review Conversations

• I replied to or resolved every bot review conversation I addressed in this PR.
• I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

• Backward compatible? Yes
• Config/env changes? No
• Migration needed? No

Risks and Mitigations

• Risk: isExpectedReconnectExhausted might suppress a genuine exhaustion if something else sets maxAttempts=0.
  • Mitigation: maxAttempts=0 is only set in one place (provider.lifecycle.reconnect.ts:404, the onAbort handler). The negative regression test guards against over-suppression.

🤖 Generated with Claude Code

Changed files

• extensions/discord/src/monitor/provider.lifecycle.test.ts (modified, +24/-9)
• extensions/discord/src/monitor/provider.lifecycle.ts (modified, +5/-6)

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

• Repository: openclaw/openclaw
• Author: openperf
• State: closed | 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.test.ts (modified, +100/-4)
• extensions/discord/src/monitor/provider.lifecycle.ts (modified, +25/-0)