hermes - 💡(How to fix) Fix fix(qqbot): Reconnect loop with stale session — adapter never falls back to fresh Identify

Summary

When the QQ Bot WebSocket disconnects and the old session expires on the server side, the adapter enters an infinite reconnect loop trying to Resume with the stale session_id. It never falls back to a fresh Identify handshake, so the bot stays offline indefinitely until the container is manually restarted.

Environment

• Hermes Agent v0.13.0 (ghcr.io/zpvel/hermes-agent-ghcr:latest)
• Docker on NAS
• Platform: qqbot (app_id: 1903797772)

What happened

1. WebSocket disconnected (likely network blip or server-side idle timeout).
2. Adapter attempted to Resume with the old session_id and seq number.
3. QQ server accepted the resume but immediately closed the WebSocket.
4. Adapter waited 2s, reconnected, sent Resume again with the same stale session_id.
5. This loop repeated for hours (seq went from ~198 to 205+) until the reconnect eventually failed with:

   WARNING  Reconnect failed: Failed to get QQ Bot gateway URL: Server disconnected without sending a response.

6. Gateway state became disconnected and never recovered.

Log excerpt (repeats identically):

INFO     WebSocket connected to wss://api.sgroup.qq.com/websocket
INFO     Reconnected
INFO     Resume sent (session_id=46592058-7601-4854-8ef7-0b5527f67bd2, seq=201)
INFO     Session resumed
WARNING  WebSocket error: WebSocket closed
INFO     Reconnecting in 2s (attempt 1)...

Expected behavior

After N consecutive Resume failures (e.g. 3), the adapter should:

1. Discard the stale session.
2. Send a fresh Identify to establish a new session.
3. Resume normal operation.

This is the standard pattern for Discord-style WebSocket gateways, which QQ Bot's protocol is based on.

Actual behavior

The adapter retries Resume indefinitely with the same expired session_id, never creating a new session. The bot remains offline until the container is manually restarted.

Workaround

Restart the Hermes gateway container:

docker restart hermes-gateway

Additional context

Possibly related to #19648, #19821, #15490 — but this specific failure mode (stale session resume loop without fallback to Identify) does not appear to be covered by existing issues.