hermes - 💡(How to fix) Fix Feishu WebSocket disconnect causes full gateway restart every ~30min [1 pull requests]

Summary

When Feishu (Lark) is connected via WebSocket, the connection drops approximately every 30 minutes with:

[Lark] ERROR: receive message loop exit, err: no close frame received or sent
→ Stopping gateway for restart...

This triggers a full gateway restart (all adapters disconnect/reconnect, shutdown notification sent to all active sessions), rather than just reconnecting the Feishu WebSocket.

Impact

• 48 restarts per day (every ~30 min, around the clock)
• Each restart sends a verbose notification to all active chat sessions
• Active tasks get interrupted unnecessarily
• DingTalk and other platforms also disconnect/reconnect even though they're fine

Expected behavior

Feishu WebSocket reconnection should be handled at the adapter level (reconnect the WebSocket) without restarting the entire gateway process. Other platforms (DingTalk, Slack, etc.) should be unaffected.

Environment

• Hermes Agent v0.14.0 (2026.5.16)
• macOS 26.5 (Apple Silicon)
• Connected platforms: DingTalk (stream mode) + Feishu (websocket mode)
• Installed via Homebrew

Logs

2026-05-24 12:33:34 [Lark] ERROR: receive message loop exit, err: no close frame received or sent [conn_id=...]
2026-05-24 12:33:34 [Lark] INFO: disconnected to wss://msg-frontier.feishu.cn/...
2026-05-24 12:33:40 INFO: Stopping gateway for restart...
2026-05-24 12:33:40 INFO: ✓ dingtalk disconnected
2026-05-24 12:33:40 INFO: ✓ feishu disconnected
2026-05-24 12:33:42 INFO: Starting Hermes Gateway...
2026-05-24 12:33:42 INFO: ✓ dingtalk connected
2026-05-24 12:33:42 INFO: ✓ feishu connected

The 30-minute cycle is consistent — see restart timestamps from a single day:

00:53, 01:23, 01:53, 02:23, 02:53, 03:24, 03:54, 04:24, 04:54, 05:25, 05:55, 06:25, 06:55, 07:26, 07:56, 08:26, 08:56, 09:26, 09:57, 10:27, 10:57, 11:27, 11:57, 12:33, 13:03, 13:34, 14:04, 14:34, 15:04, 15:35

Suggested fix

Handle Feishu WebSocket no close frame errors at the adapter level:

1. Catch the disconnect in the Feishu adapter
2. Attempt WebSocket reconnection (with backoff)
3. Only escalate to full gateway restart if reconnection fails after N retries

This aligns with how most messaging SDKs handle transient WebSocket disconnects gracefully.