Summary

Fixes #37364 — send_message with target="wecom" and a MEDIA: directive was silently dropping the attachment. The text message still delivered, but the media fell through to the "Non-media platforms" catch-all and was discarded.

Root cause

Two layered problems:

1. No media branch. _send_to_platform() in tools/send_message_tool.py had a dedicated media_files branch for Telegram, Weixin, Discord, Matrix, Signal, Yuanbao, and Feishu — but not WeCom. WeCom media hit the generic non-media catch-all (lines ~825-838 pre-fix) and was dropped with a warning.

2. Standalone path can't connect. The fallback text-only _send_wecom() instantiates its own WeComAdapter and calls connect(). WeCom enforces a single WebSocket per bot, so this fails with errcode 846609: aibot websocket not subscribed whenever the gateway is already running with the same credentials.

Fix

Add a Platform.WECOM and media_files branch in _send_to_platform() that dispatches to a new _send_wecom_via_adapter() helper. The helper:

1. Grabs the live WeComAdapter from the running gateway via _gateway_runner_ref() (so the existing WebSocket is reused).
2. Sends the text message via adapter.send(chat_id, content).
3. For each media attachment, dispatches to send_image_file, send_document, send_voice, or send_video based on file extension (same dispatch logic used by Feishu and Matrix).
4. Returns a clear error when media is requested but no live adapter is reachable (e.g. cron running in a separate process from the gateway — WeCom simply does not support that case for media).
5. Falls through to the legacy _send_wecom() for text-only sends, so the existing text contract is unchanged.

I deliberately did not touch the standalone text-only path. The issue (#37364) is scoped to media delivery, and the text-only WebSocket conflict is a separate concern — left a note in the docstring for follow-up.

Why not the "clear _last_chat_req_ids" approach suggested in the issue?

The issue proposed clearing _last_chat_req_ids[chat_id] before the send so the adapter falls through to proactive (aibot_send_msg) mode. I considered it and rejected it: WeCom AI Bots in group chats cannot use APP_CMD_SEND proactively (see tests/gateway/test_wecom.py lines ~794-833, plus the comment in gateway/platforms/wecom.py:900). In groups, every send MUST be an APP_CMD_RESPONSE bound to an inbound req_id. The existing _send_media_source() already does the right thing — if a cached req_id exists for the chat, it replies; otherwise it sends proactively. The helper just calls into that existing logic, so group chats keep working.

Tests

• TestSendWecomMedia — 2 cases: Platform.WECOM and media_files now dispatches to the helper; text-only still hits the legacy path.
• TestSendWecomViaAdapter — 3 cases: live adapter dispatches image vs. document correctly, no live adapter returns a helpful error for media, no live adapter falls back for text-only.

5 new tests pass. Full file: 134 passed. WeCom gateway tests: 46 passed.

Files changed

• tools/send_message_tool.py — new helper, new branch, updated user-facing supported-platforms list.
• tests/tools/test_send_message_tool.py — 5 new tests.

Risk

Low. The change is additive: a new if branch that is only entered when media_files is non-empty AND platform is WeCom. Text-only behavior is byte-identical. The new helper mirrors the dispatch pattern already used for Feishu and Matrix.

Related

• [QQ Bot] send_message MEDIA files are silently dropped — never attempted #37315 — same pattern needed for QQ Bot (separate fix)
• MEDIA: tag fails silently for .md files — extract_media() regex whitelist missing common extensions #37318 — MEDIA tag extraction issues with .md files (separate fix)