Skip to content

fix(wecom): add CLOSING state to _wait_for_handshake auth guard (#64703) - #64727

Closed
xxiaoxiong wants to merge 1 commit into
NousResearch:mainfrom
xxiaoxiong:fix/64703-wecom-ws-closing
Closed

xxiaoxiong wants to merge 1 commit into
NousResearch:mainfrom
xxiaoxiong:fix/64703-wecom-ws-closing

Conversation

@xxiaoxiong

Copy link
Copy Markdown

Summary

Fixes #64703.

_wait_for_handshake() in plugins/platforms/wecom/adapter.py did not handle aiohttp.WSMsgType.CLOSING, causing permanent reconnect failure when the server sent a closing frame during the authentication handshake.

Root cause

When #28311 fixed _read_events() to handle WSMsgType.CLOSING (issue #28293), _wait_for_handshake() was missed. Both functions receive WebSocket messages and need to handle all terminal states, but _wait_for_handshake() was missing CLOSING:

Before: {WSMsgType.CLOSED, WSMsgType.CLOSE, WSMsgType.ERROR}
After: {WSMsgType.CLOSED, WSMsgType.CLOSE, WSMsgType.ERROR, WSMsgType.CLOSING}

The _read_events() set already includes CLOSING (since #28311).

Impact

All reconnection attempts fail silently (backoff retries all hit the same hang), requiring a manual pod/agent restart to recover. In production: 9/14 WeCom agents permanently lost connectivity after a cluster restart.

Testing

One-character change (constant added to a set). Matches the identical set in _read_events() (line 373).

…Research#64703)

_wait_for_handshake() had the same gap that NousResearch#28311 fixed in _read_events():
WSMsgType.CLOSING was not handled, causing permanent reconnect failure when
the server sent a CLOSING frame during the authentication handshake.

The websocket closed permanently (all retry backoffs fail silently) and the
only recovery was a manual pod/agent restart. After a mass gateway restart,
9/14 production WeCom agents lost connectivity.

Add WSMsgType.CLOSING to the terminal-state set in _wait_for_handshake(),
matching the existing set in _read_events() (which already includes it).
@alt-glitch alt-glitch added type/bug Something isn't working comp/plugins Plugin system and bundled plugins platform/wecom WeCom / WeChat Work adapter sweeper:risk-message-delivery Sweeper risk: may drop, duplicate, misroute, or suppress messages P2 Medium — degraded but workaround exists duplicate This issue or pull request already exists labels Jul 15, 2026
@alt-glitch

Copy link
Copy Markdown

This was generated by AI during triage.

Duplicate of #64716 — identical one-line fix (adds aiohttp.WSMsgType.CLOSING to the _wait_for_handshake() terminal-state set). #64716 is the earliest open PR for this fix; #64707 was the closed first attempt. This also fixes open issue #64703. Deferring to #64716 as canonical.

@xxiaoxiong

Copy link
Copy Markdown
Author

Closing as duplicate of #64716 (same CLOSING state fix, submitted first). Thanks @alt-glitch for the triage note — good catch.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

comp/plugins Plugin system and bundled plugins duplicate This issue or pull request already exists P2 Medium — degraded but workaround exists platform/wecom WeCom / WeChat Work adapter sweeper:risk-message-delivery Sweeper risk: may drop, duplicate, misroute, or suppress messages type/bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

fix(wecom): _wait_for_handshake missing CLOSING state causes permanent reconnect failure after mass restart

2 participants