Bug Description
When the WeCom (WeWork) WebSocket connection enters WSMsgType.CLOSING state (e.g., during network interruption or server-side close), the _read_events() loop in gateway/platforms/wecom.py does not handle this message type. This causes receive() to immediately return CLOSING again, resulting in a tight loop that consumes 45-100% CPU.
Root Cause
The elif branch checking for terminal WebSocket states only includes:
aiohttp.WSMsgType.CLOSEaiohttp.WSMsgType.CLOSEDaiohttp.WSMsgType.ERROR
It is missing aiohttp.WSMsgType.CLOSING.
Environment
- Python 3.11+
- aiohttp (any version with WSMsgType.CLOSING)
- Hermes Agent main branch
Reproduction Steps
- Start gateway with WeCom platform enabled:
hermes gateway run
- Trigger a network interruption or wait for server-side close
- Observe CPU usage spike to 45-100% in
hermes_cli.main gateway run process
- Gateway logs show no error, but process is spinning
Expected Behavior
Gateway should recognize CLOSING as a terminal state, close the connection gracefully, and reconnect.
Actual Behavior
CPU spins at 45-100% until process is manually killed.
Bug Description
When the WeCom (WeWork) WebSocket connection enters
WSMsgType.CLOSINGstate (e.g., during network interruption or server-side close), the_read_events()loop ingateway/platforms/wecom.pydoes not handle this message type. This causesreceive()to immediately returnCLOSINGagain, resulting in a tight loop that consumes 45-100% CPU.Root Cause
The
elifbranch checking for terminal WebSocket states only includes:aiohttp.WSMsgType.CLOSEaiohttp.WSMsgType.CLOSEDaiohttp.WSMsgType.ERRORIt is missing
aiohttp.WSMsgType.CLOSING.Environment
Reproduction Steps
hermes gateway runhermes_cli.main gateway runprocessExpected Behavior
Gateway should recognize CLOSING as a terminal state, close the connection gracefully, and reconnect.
Actual Behavior
CPU spins at 45-100% until process is manually killed.