Summary

• Problem: Discord can appear running while the transport is degraded or the Gateway event loop is starved, which makes intermittent socket resets look like healthy channel state.
• Why it matters: Issue Discord inbound messages not reaching agent after gateway reconnects #75346 needed end-to-end evidence for Discord stall/reset diagnostics, including Dave's follow-up symptoms where a stalled runtime hid useful health signals.
• What changed: propagate Gateway event-loop health into channel/status summaries, annotate channel account health, surface Discord degraded transport issues, and add fetch-timeout timer-delay diagnostics.
• What did NOT change (scope boundary): no Discord auth, delivery routing, reconnect policy, or provider behavior changes.

Change Type (select all)

• Bug fix
• Feature
• Refactor required for the fix
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Closes Discord inbound messages not reaching agent after gateway reconnects #75346
• Related Discord inbound messages not reaching agent after gateway reconnects #75346
• This PR fixes a bug or regression

Root Cause (if applicable)

• Root cause: channels.status and status --deep reported process/account running state without carrying the existing Gateway event-loop health or per-account channel health classification through the RPC and CLI surfaces.
• Missing detection / guardrail: fetch timeout logs did not distinguish nominal request timeout from a timer firing late because the Node event loop was starved.
• Contributing context (if known): live Discord validation found that actual transport stalls can leave the user-facing status path looking healthier than the runtime behavior.

Regression Test Plan (if applicable)

• Coverage level that should have caught this:
  • Unit test
  • Seam / integration test
  • End-to-end test
  • Existing coverage already sufficient
• Target test or file: src/gateway/server-methods/channels.status.test.ts, src/commands/channels.surfaces-signal-runtime-errors-channels-status-output.test.ts, src/commands/status.command-sections.test.ts, extensions/discord/src/status-issues.test.ts, src/utils/fetch-timeout.test.ts.
• Scenario the test should lock in: degraded event-loop and channel health are visible in status outputs, Discord status issues include stale/stuck transport states, and late timeout timers log timer-delay hints.
• Why this is the smallest reliable guardrail: the tests cover the RPC payload seams, CLI rendering, Discord issue collector, and fetch-timeout diagnostics without requiring live Discord for every run.
• Existing test that already covers this (if any): existing channel status tests covered running/configured rows, but not degraded event-loop or account health propagation.
• If no new test is added, why not: N/A.

User-visible / Behavior Changes

openclaw channels status, openclaw status --deep, Discord status issue output, and fetch-timeout logs now include degraded transport/event-loop starvation hints when the Gateway has the data.

Diagram (if applicable)

Before:
Discord transport stall -> channel account still shown as running -> operator lacks stall clue

After:
Discord transport stall -> health/event-loop state flows into status -> operator sees degraded/stale/stuck hint

Security Impact (required)

• New permissions/capabilities? (Yes/No) No
• Secrets/tokens handling changed? (Yes/No) No
• New/changed network calls? (Yes/No) No
• Command/tool execution surface changed? (Yes/No) No
• Data access scope changed? (Yes/No) No
• If any Yes, explain risk + mitigation: N/A

Repro + Verification

Environment

• OS: macOS host plus Docker live reproduction; Testbox Linux CI-parity changed gate.
• Runtime/container: Docker image openclaw-75346-hardened-status for patched live validation; current branch rebased on latest origin/main.
• Model/provider: OpenAI key available for live path where needed; no model response changes in this PR.
• Integration/channel (if any): live Discord bot/guild/channel validation with secrets redacted.
• Relevant config (redacted): Discord bot token, guild ID, channel ID, user ID, and OpenAI API key supplied outside git.

Steps

1. Reproduced the current-branch issue behavior before patch with live Discord/Docker validation.
2. Applied status hardening and regression tests.
3. Rebuilt and ran patched Docker live validation with a forced event-loop stall.
4. Verified CLI/RPC status output and fetch-timeout logs surfaced degraded event-loop and transport health.

Expected

• Status paths identify degraded Discord transport and event-loop starvation instead of reporting only healthy running state.

Actual

• Patched status returned after the forced stall with eventLoop.degraded: true, and the CLI/status issue paths expose the degraded health signals.

Evidence

• Failing test/log before + passing after
• Trace/log snippets
• Screenshot/recording
• Perf numbers (if relevant)

Validation run after rebase:

• git diff --check
• pnpm exec oxfmt --check --threads=1 CHANGELOG.md
• pnpm check:changelog-attributions
• pnpm test src/gateway/server-methods/channels.status.test.ts extensions/discord/src/status-issues.test.ts src/commands/channels.surfaces-signal-runtime-errors-channels-status-output.test.ts src/commands/status.command-sections.test.ts src/utils/fetch-timeout.test.ts
• Testbox OPENCLAW_TESTBOX=1 pnpm check:changed on tbx_01kqnjpj34468hzpshgp60hz8p

Human Verification (required)

• Verified scenarios: live Discord current-branch reproduction, patched Docker event-loop-stall validation, CLI/status rendering, RPC payload propagation, Discord issue collection, fetch-timeout late-timer logging.
• Edge cases checked: degraded Gateway event loop, account health states including stale/stuck/disconnected/not-running, running-but-not-connected Discord account state, late timeout timer delay hints.
• What you did not verify: Dave's exact Linux x64 / Node 22.22.2 machine; validation used available Docker/Linux-equivalent and maintainer live Discord credentials.

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/No) Yes
• Config/env changes? (Yes/No) No
• Migration needed? (Yes/No) No
• If yes, exact upgrade steps: N/A

Risks and Mitigations

• Risk: Status output gains new optional health fields that callers might not expect.
  • Mitigation: fields are additive/optional, and existing summaries remain intact.
• Risk: Event-loop starvation diagnostics could be noisy in severe host overload.
  • Mitigation: warnings are only added when existing health state or timeout elapsed-vs-budget evidence indicates degradation.