fix(qqbot): accept is_reconnect kwarg in QQAdapter.connect

[ijevin]

Summary

The v0.18.0 refactor (commit 7c1a029) added a keyword-only is_reconnect: bool = False argument to BasePlatformAdapter.connect() so the gateway's reconnect watcher can ask adapters to preserve their server-side update queue when re-establishing a dropped platform.

QQAdapter.connect() in gateway/platforms/qqbot/adapter.py was not updated in the same release, so every reconnect attempt raises:

TypeError: connect() got an unexpected keyword argument 'is_reconnect'

The QQBot platform then enters the watchdog's fatal-error state and can never come back, even on a fresh v0.18.0 install.

Rationale

The contract docstring on BasePlatformAdapter.connect() says:

Adapters that buffer a server-side update queue (e.g. Telegram's Bot API) should preserve that queue when is_reconnect is True so messages sent during the outage are delivered rather than silently discarded. Adapters with no such queue may ignore the flag.

QQ Bot has no server-side update queue — every inbound message is pushed live over the WebSocket — so the flag is accepted and intentionally ignored, mirroring the same pattern already used by the other adapters in this release.

Diff

One-file change in gateway/platforms/qqbot/adapter.py:

-    async def connect(self) -> bool:
-        """Authenticate, obtain gateway URL, and open the WebSocket."""
+    async def connect(self, *, is_reconnect: bool = False) -> bool:
+        """Authenticate, obtain gateway URL, and open the WebSocket.
+
+        ``is_reconnect`` is part of the BasePlatformAdapter.connect contract
+        introduced for the gateway's reconnect watcher. QQ Bot has no
+        server-side update queue to preserve (each message is pushed live over
+        the WebSocket), so the flag is accepted and ignored — the watcher
+        otherwise raises TypeError and the QQ platform can never come back.
+        """

• 8 lines added, 2 lines replaced — function body unchanged
• Default False preserves cold-start behavior identical to v0.17.x
• Docstring records the contract origin so future refactors don't drop the flag again

Verification

Applied this patch on top of v0.18.0 (local checkout 30e947e0 + 1af7d6580 ahead). After bringing the gateway back up:

Check	Result
tail ~/.hermes/logs/gateway.log shows Connected	OK
~/.hermes/gateway_state.json has qqbot.state == "online"	OK
Reconnect attempts no longer raise TypeError: ... is_reconnect	OK
Inbound QQ messages flow as expected (one round-trip confirmed in production)	OK

Static checks performed on the same VPS:

Check	Result
py_compile of modified adapter.py	OK
inspect.signature(QQAdapter.connect) matches abstract signature	(self, *, is_reconnect: bool = False) -> bool
is_reconnect parameter is KEYWORD_ONLY with default False	OK
Stub run with await adapter.connect(is_reconnect=True) reaches end of function (no TypeError)	OK

Reproduction

$ pip install --upgrade hermes-agent==0.18.0
$ # add qqbot platform to ~/.hermes/config.yaml with app_id / app_secret / token
$ # start the gateway normally (e.g. systemctl start hermes-gateway)
$ tail -f ~/.hermes/logs/gateway.log
# ...observe "TypeError: connect() got an unexpected keyword argument 'is_reconnect'"
# ...observe qqbot platform enters fatal-error state and never reconnects

After applying this patch the same sequence produces a stable Connected state and the reconnect watcher can no longer crash the platform.

[alt-glitch]

This was generated by AI during triage.

Duplicate of #52966 — same one-line fix adding the keyword-only is_reconnect kwarg to QQAdapter.connect() so the gateway reconnect watcher stops raising TypeError (QQBot never reconnects otherwise). This is a heavily saturated cluster of identical fixes for #52914; the original anchor #52922 is now closed, so the earliest still-open fix PR #52966 is canonical. Related: #52914 (the issue).