PR #11572: fix(wecom): resolve WebSocket zombie sessions and group chat 600039 e…

• Repository: NousResearch/hermes-agent
• Author: devorun
• State: closed | merged: False
• Link: https://github.com/NousResearch/hermes-agent/pull/11572

Description (problem / solution / changelog)

…rrors #11554

What does this PR do?

This PR addresses two critical issues with the WeCom AI Bot WebSocket gateway integration, specifically resolving #11554.

1. Silent Message Drops on Reconnect: When the WebSocket reconnects, the WeCom server keeps the previous session alive as a "zombie", routing inbound group messages to the dead connection instead of the new one.
2. WeCom errcode 600039 in Group Chats: WeCom AI Bots are restricted from sending proactive messages (APP_CMD_SEND) in group chats and must reply to an existing req_id (APP_CMD_RESPONSE). Additionally, the stream message type is unsupported on many WeCom mobile clients, triggering the same 600039 error.

Changes Made

• Added device_id to aibot_subscribe: Generating and persisting a device_id per adapter instance ensures the WeCom server correctly overrides the old zombie session and re-routes messages upon reconnection.
• Replaced stream with markdown: Removed _send_reply_stream in favor of _send_reply_markdown to ensure message formatting compatibility across all WeCom clients.
• Implemented req_id caching for group fallbacks: The adapter now tracks the last seen req_id for each chat_id (_last_chat_req_ids). If the bot attempts to send a message to a group without a specific reply_to context, it gracefully falls back to sending a reply using the cached req_id, bypassing the proactive send restriction.

Related Issue

Fixes #11554

Testing

• Verified WebSocket reconnects no longer result in silent message drops.
• Verified bot can successfully send messages to group chats without hitting the 600039: device type not support error.

<!-- Describe the change clearly. What problem does it solve? Why is this approach the right one? -->

Related Issue

<!-- Link the issue this PR addresses. If no issue exists, consider creating one first. -->

Fixes #

Type of Change

<!-- Check the one that applies. -->

• 🐛 Bug fix (non-breaking change that fixes an issue)
• ✨ New feature (non-breaking change that adds functionality)
• 🔒 Security fix
• 📝 Documentation update
• ✅ Tests (adding or improving test coverage)
• ♻️ Refactor (no behavior change)
• 🎯 New skill (bundled or hub)

Changes Made

<!-- List the specific changes. Include file paths for code changes. -->

How to Test

<!-- Steps to verify this change works. For bugs: reproduction steps + proof that the fix works. -->

Checklist

<!-- Complete these before requesting review. -->

Code

• I've read the Contributing Guide
• My commit messages follow Conventional Commits (fix(scope):, feat(scope):, etc.)
• I searched for existing PRs to make sure this isn't a duplicate
• My PR contains only changes related to this fix/feature (no unrelated commits)
• I've run pytest tests/ -q and all tests pass
• I've added tests for my changes (required for bug fixes, strongly encouraged for features)
• I've tested on my platform: <!-- e.g. Ubuntu 24.04, macOS 15.2, Windows 11 -->

Documentation & Housekeeping

<!-- Check all that apply. It's OK to check "N/A" if a category doesn't apply to your change. -->

• I've updated relevant documentation (README, docs/, docstrings) — or N/A
• I've updated cli-config.yaml.example if I added/changed config keys — or N/A
• I've updated CONTRIBUTING.md or AGENTS.md if I changed architecture or workflows — or N/A
• I've considered cross-platform impact (Windows, macOS) per the compatibility guide — or N/A
• I've updated tool descriptions/schemas if I changed tool behavior — or N/A

For New Skills

<!-- Only fill this out if you're adding a skill. Delete this section otherwise. -->

• This skill is broadly useful to most users (if bundled) — see Contributing Guide
• SKILL.md follows the standard format (frontmatter, trigger conditions, steps, pitfalls)
• No external dependencies that aren't already available (prefer stdlib, curl, existing Hermes tools)
• I've tested the skill end-to-end: hermes --toolsets skills -q "Use the X skill to do Y"

Screenshots / Logs

<!-- If applicable, add screenshots or log output showing the fix/feature in action. -->

Changed files

• gateway/platforms/wecom.py (modified, +22/-11)

---

PR #11656: fix(wecom): watchdog + reset _last_msg_at on reconnect to fix silent group message loss

• Repository: NousResearch/hermes-agent
• Author: olbwmly-png
• State: closed | merged: False
• Link: https://github.com/NousResearch/hermes-agent/pull/11656

Description (problem / solution / changelog)

Problem

WeCom AI Bot WebSocket connections experience silent message delivery failures after reconnects:

1. The WebSocket drops and reconnects every ~5 minutes.
2. After reconnect, the connection appears healthy (pings flow), but inbound group messages () stop arriving.
3. The auto-reconnect only reset , leaving stale. This caused the watchdog (if present) to miscalculate idle time.

Changes

• **Add **: Monitors inbound message flow. If no arrives within (default 300s) after the connection has been up for 2 minutes, it force-closes the socket so reconnects and re-subscribes.
• **Track and **: Updated on every real message callback.
• Reset on reconnect: Fixes the bug where the watchdog used the previous connection's last message time.
• Disable reply-stream for groups entirely: Proactive works reliably for both DMs and groups, while reply streams silently fail in groups with errcode 600039.
• Improve logging: Added inbound/outbound payload logging for easier debugging.

Testing

• Watchdog successfully detected a stalled connection (~59 min without group messages) and forced a reconnect.
• After reconnect, group messages () resumed immediately.
• Reply sending now consistently returns .

Closes #11554

Changed files

• gateway/platforms/wecom.py (modified, +88/-5)

---

PR #11897: fix(wecom): resolve WebSocket zombie sessions and group chat 600039 errors (#11554)

• Repository: NousResearch/hermes-agent
• Author: teknium1
• State: closed | merged: True
• Link: https://github.com/NousResearch/hermes-agent/pull/11897

Description (problem / solution / changelog)

Summary

WeCom AI Bot WebSocket reconnects no longer silently drop inbound group messages, and group replies no longer fail with errcode 600039: device type not support. Fixes #11554.

Root cause

Three interacting WeCom protocol quirks:

1. aibot_subscribe didn't include a device_id, so on reconnect the WeCom server kept routing inbound callbacks to the old (zombie) session.
2. _send_reply_stream used msgtype: stream, which is unsupported on many WeCom mobile clients and triggers errcode 600039.
3. WeCom AI Bots can't initiate APP_CMD_SEND in group chats at all — proactive sends to groups must piggyback on a prior inbound req_id via APP_CMD_RESPONSE.

Approach

Salvaged from #11572 (devorun):

• Generate a stable device_id per adapter instance and include it in the subscribe body so WeCom takes over the zombie session on reconnect.
• Replace _send_reply_stream with _send_reply_markdown (msgtype markdown) so replies render on all WeCom clients.
• Cache the most recent inbound req_id per chat, and fall back to it for proactive sends when no explicit reply_to is available — required for group sends.

Follow-up fixes applied on top during salvage:

• Bounded the req_id cache. Extracted _remember_chat_req_id() helper and capped it at DEDUP_MAX_SIZE like the existing _reply_req_ids eviction — otherwise a long-running gateway with many chats leaks memory forever.
• Moved cache write to after the policy check. We don't cache req_ids from blocked senders.
• Reverted the undocumented is_group change. The original PR flipped chattype == "group" to bool(chatid) without mentioning it — that weakens the signal since chattype is the explicit hint. Kept the original check.
• Dropped defensive getattr(self, '_last_chat_req_ids', {}) reads at both send sites — the attribute is initialized in __init__.
• Added tests. New TestWeComZombieSessionFix class covering: device_id presence in subscribe, distinct device_ids per instance, per-chat req_id caching, blocked-sender cache exclusion, cache bounding, and the group APP_CMD_RESPONSE fallback. Also updated the existing test_send_uses_passive_reply_stream_when_reply_context_exists → _markdown_... to match the new msgtype.

Why this over #11656 (competing PR)

#11656 (olbwmly-png) tried to solve the same bug by adding a 5-minute watchdog that force-reconnects when no callbacks arrive, plus a fallback-on-600039 path. That's a defensive workaround — if device_id really is the missing piece, each watchdog-driven reconnect would fail the same way. #11572's targeted protocol fix (device_id + markdown + req_id fallback) addresses the root cause. The watchdog idea is valid as defense-in-depth and a follow-up PR adding it on top would be welcome. Closing #11656 with credit.

Changes

Validation

Merge method

Please rebase-merge (gh pr merge --rebase) — the first commit is authored by Devorun and must keep that authorship. Squash would collapse both commits under the merger.

Closes #11554. Supersedes and will close #11572 (devorun, cherry-picked with authorship preserved) and #11656 (olbwmly-png, watchdog approach — welcome as a follow-up).

Changed files

• gateway/platforms/wecom.py (modified, +41/-10)
• tests/gateway/test_wecom.py (modified, +195/-4)