PR #54973: fix(discord): suppress reconnect-exhausted crash during health-monitor restart

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

Description (problem / solution / changelog)

Summary

Fixes #54931 — Discord health-monitor triggers uncaught exception crash loop.

Root Cause

When the health-monitor detects a stale socket and restarts a Discord channel:

1. stopChannel() aborts the controller
2. onAbort() sets gateway.options.reconnect = { maxAttempts: 0 } and calls disconnect()
3. Carbon emits "Max reconnect attempts" error asynchronously

Two race conditions caused this to crash:

1. Error rethrown during intentional shutdown: startDiscordLifecycle catch block rethrew the reconnect-exhausted error even when lifecycleStopping=true (abort was intentional)
2. Supervisor disposed too early: gatewaySupervisor.dispose() removed the error listener immediately in the finally block. Late async errors from Carbon had no listener and became uncaught EventEmitter errors crashing the process.

Fix

1. provider.lifecycle.ts: Suppress reconnect-exhausted errors in the catch block when lifecycleStopping is true (intentional shutdown)
2. provider.ts: Defer gatewaySupervisor.dispose() by 5 seconds so late errors are handled in the supervisor's teardown phase instead of crashing

Testing

The crash occurs ~35 minutes after startup when the health-monitor fires. Both changes are defensive guards that only activate during intentional shutdown (abort signal), so they cannot affect normal reconnection behavior.

Changed files

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

---

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: 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)

---

PR #202: 🦅 Scout: Critical Inherited Defect Report - 2026-03-24

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

Description (problem / solution / changelog)

🦅 Scout: Critical Inherited Defect Report - 2026-03-24

Scanned the upstream OpenClaw repository and identified 3 defect patterns representing critical/high-impact regressions introduced in the recent v2026.3.24 release that are present in our local codebase:

Upstream Issue #54931: BUG: Discord health-monitor triggers uncaught exception crash loop

• Location in our code: src/discord/monitor/provider.lifecycle.ts
• Observed Behavior: The Discord health-monitor handles aborts by setting gateway.options.reconnect = { maxAttempts: 0 } and calling gateway.disconnect(). When the WebSocket close handler immediately fires, it checks reconnectAttempts(0) >= maxAttempts(0), evaluating to true, which emits a new Error that goes uncaught, crashing the entire Node.js process and disrupting all subagent sessions.
• Expected Behavior: Health-monitor should gracefully restart the Discord channel without crashing the gateway process. The forced disconnection path shouldn't invoke the unexpected connection-retry limits error logic, or if it does, the error should be correctly caught instead of bringing down the gateway process.
• Impact Severity: High — Gateway crashes periodically (every ~35 mins) if Discord goes stale. All running subagent sessions are disrupted or killed.

Upstream Issue #54936: BUG: Subagent runTimeoutSeconds default fallback resolves to infinite timeout instead of configured default

• Location in our code: src/agents/subagent-registry.ts
• Observed Behavior: When a subagent is spawned via sessions_spawn without explicitly passing a runTimeoutSeconds parameter, the parameter initializer mistakenly falls back to 0. The downstream timeout resolver interprets 0 as an explicit "disable timeout" instruction, causing the subagent to run indefinitely rather than falling back to the configured default (agents.defaults.subagents.runTimeoutSeconds).
• Expected Behavior: Subagents should be killed after the configured default runtime timeout when no explicit timeout is passed during the spawn call.
• Impact Severity: Medium — Subagents spawned without explicit timeouts will run indefinitely, potentially creating zombie processes that stall and exhaust system resources.

Upstream Issue #54975: BUG: All tools with required parameters receive empty {} arguments - Gateway parameter parsing failure

• Location in our code: Provider integrations (Anthropic/OpenAI compat)
• Observed Behavior: Third-party providers fail to correctly serialize/send tool parameters, causing validation failures where the agent's intent is lost. Tools receive empty {} arguments instead of the correctly passed parameters.
• Expected Behavior: Tools should receive the correctly passed parameters and execute successfully.
• Impact Severity: High — Complete automation blockage when using specific models.

The .jules/scout.md journal has been updated with these patterns for future tracking.

---

PR created automatically by Jules for task 2111446781902950035 started by @MillionthOdin16

<!-- This is an auto-generated comment: release notes by coderabbit.ai -->

Summary by CodeRabbit

• Documentation
  • Added documentation for known defect patterns and tracked issues.

<!-- end of auto-generated comment: release notes by coderabbit.ai -->

Changed files

• .jules/scout.md (added, +14/-0)
• report.txt (added, +13/-0)