fix(discord): recover from runtime gateway task exits

[austinpickett]

Salvage of #39416 (AMEOBIUS). Cherry-picked the 2-file fix from a branch that was 1081 commits behind with 28 unrelated commits. Original author was silent for 5+ days after a split-out request.

What this fixes

A post-ready discord.py WebSocket crash (e.g. ClientOSError, ConnectionResetError) left the gateway split-brained: producer tasks stayed alive while Discord stopped responding. The adapter had no task-exit callback, so no reconnect was ever triggered.

Changes

• plugins/platforms/discord/adapter.py — adds _handle_bot_task_done callback wired into Bot.start()'s wrapping task via add_done_callback. On any post-ready exit, calls _set_fatal_error(retryable=True) + _notify_fatal_error() so the existing GatewayRunner._handle_adapter_fatal_error reconnect watcher replaces the dead adapter. Also adds _wait_for_ready_or_bot_exit() so startup failures (SOCKS/proxy errors, invalid tokens) surface immediately instead of burning the full ready timeout.
• tests/plugins/test_discord_runtime_failure.py — 2 tests: (1) runtime task exit triggers retryable fatal notification, (2) ready event resolves normally when startup succeeds.

Verification

Both tests pass locally (2 passed in 0.29s). Hooks (_set_fatal_error, _notify_fatal_error, _handle_adapter_fatal_error) confirmed present on main.

Closes #39416.

[github-actions]

🔎 Lint report: salvage/39416-discord-task-exit-recovery vs origin/main

ruff

Total: 0 on HEAD, 0 on base (➖ 0)

🆕 New issues: none

✅ Fixed issues: none

Unchanged: 0 pre-existing issues carried over.

ty (type checker)

Total: 10763 on HEAD, 10758 on base (🆕 +5)

🆕 New issues (4):

Rule	Count
unresolved-attribute	2
invalid-assignment	1
unresolved-import	1

First entries

tests/plugins/test_discord_runtime_failure.py:47: [invalid-assignment] invalid-assignment: Object of type `AsyncMock` is not assignable to attribute `_notify_fatal_error` of type `def _notify_fatal_error(self) -> CoroutineType[Any, Any, None]`
tests/plugins/test_discord_runtime_failure.py:38: [unresolved-attribute] unresolved-attribute: Object of type `bound method DiscordAdapter._notify_fatal_error() -> CoroutineType[Any, Any, None]` has no attribute `assert_awaited_once`
tests/plugins/test_discord_runtime_failure.py:4: [unresolved-import] unresolved-import: Cannot resolve imported module `pytest`
tests/plugins/test_discord_runtime_failure.py:59: [unresolved-attribute] unresolved-attribute: Object of type `bound method DiscordAdapter._notify_fatal_error() -> CoroutineType[Any, Any, None]` has no attribute `assert_not_awaited`

✅ Fixed issues: none

Unchanged: 5632 pre-existing issues carried over.

Diagnostics are surfaced as warnings — this check never fails the build.

[tonydwb]

Code Review Summary

Verdict: Approved

Summary

Fixes Discord adapter to recover from runtime gateway task exits. Discord.py reconnects normal gateway interruptions internally, but when its top-level Bot.start() task actually exits after the adapter has been marked running, a split-brain state occurs. This PR surfaces those exits to the gateway supervisor for retry.

Changes

• Adds _wait_for_ready_or_bot_exit() that races the ready event against the bot task, surfacing early startup failures.
• Adds _handle_bot_task_done() callback to detect post-startup task exits.
• Adds _disconnecting flag to distinguish operator shutdown from crash.

Review

• Good resilience fix with proper error propagation to the gateway supervisor.
• Extensive comments explaining the Discord.py reconnect behavior.
• No security concerns.

---

Reviewed by Hermes Agent (batch cron)

[liuhao1024]

Verification — Discord runtime task exit recovery

Reviewed the split-brain prevention for Discord adapter. The design is well-structured:

1. _wait_for_ready_or_bot_exit() — Races ready_event.wait() against bot_task with asyncio.wait(FIRST_COMPLETED). If the bot task finishes first, its exception is re-raised. The finally block properly cancels and awaits the pending ready_task to avoid task leaks.

2. _handle_bot_task_done() — Three early-exit guards before declaring fatal error:

   • _disconnecting flag → intentional shutdown
   • Stale task check (task is not self._bot_task) → reconnect already replaced the task
   • not self._running → startup failures handled by connect()

   Only after all three pass does it mark _set_fatal_error(retryable=True) and notify the supervisor.

3. _disconnecting flag — Set in disconnect() before closing the client. This cleanly prevents the done-callback from treating operator-initiated shutdowns as crashes.

4. Tests — Runtime exit test confirms fatal error is set with retryable=True and supervisor is notified. Intentional disconnect test confirms no false alarm. Both pass CI.

No issues found. This addresses a real operational gap where a dead Discord websocket could leave the gateway process alive but unresponsive to Discord messages.