PR #24813: fix(gateway/feishu): in-process WS reconnect + fallback send strips thread_id

• Repository: NousResearch/hermes-agent
• Author: waynehuu
• State: open | merged: False
• Link: https://github.com/NousResearch/hermes-agent/pull/24813

Description (problem / solution / changelog)

Closes #24807, closes #24808

Problems

1. WS thread exit is silently swallowed (no in-process reconnect)

When the Feishu WebSocket thread exits unexpectedly (keepalive ping timeout escaping lark_oapi's internal reconnect loop), the exception was caught by a bare except Exception: pass in _run_official_feishu_ws_client. No fatal error was raised, so the adapter stayed registered but went deaf. Recovery required a full gateway process restart via systemd (exit 75 / TEMPFAIL), which killed any in-flight agent tasks and triggered the 60s drain timeout.

2. Fallback send fails with [99992402] field validation failed

_send_with_retry's plain-text fallback passed the original metadata unchanged. If metadata contained a stale thread_id, Feishu returned [99992402] field validation failed, making the fallback fail too.

Fixes

1. Add a done-callback on _ws_future in _connect_websocket. When the WS thread exits while the adapter is still running, the callback calls _set_fatal_error(retryable=True) and schedules _notify_fatal_error(). This wires into the existing _failed_platforms reconnect infrastructure in run.py (exponential backoff, up to _MAX_ATTEMPTS) — reconnect happens in-process without restarting the gateway.

2. Before the fallback send() call, build a copy of metadata with thread_id and reply_to_message_id stripped, so the fallback degrades to a plain top-level chat message.

Changes

• gateway/platforms/feishu.py: add _on_ws_thread_done done-callback on _ws_future
• gateway/platforms/base.py: strip thread_id/reply_to_message_id from metadata before fallback send

Changed files

• gateway/platforms/base.py (modified, +11/-2)
• gateway/platforms/feishu.py (modified, +13/-0)