Replace the boolean wecom_bot_callback with a wecom_bot_mode field
("websocket" | "webhook"), consistent with the Feishu channel's
feishu_event_mode. Update startup() and send() to branch on the mode.
Also fix a temp-file leak in _load_image_base64: downloads, format
conversions and compressions wrote to /tmp but were never removed. Track
only the temp files created here and delete them in a finally block,
leaving the caller's original local file untouched.
Co-authored-by: Cursor <cursoragent@cursor.com>
Remove the callback-mode fields (Callback Mode / Token / EncodingAESKey /
Port) from the web console channel form; these are rarely changed and are
now configured via config.json only. The console keeps Bot ID / Secret for
the long-connection setup.
Serve the callback HTTP server on a fixed path (/wecombot) instead of any
path (/.*), so unrelated requests 404 rather than being processed as
signature-failing WeCom callbacks. The bot's receive-message URL must point
at http(s)://host:<port>/wecombot.
Co-authored-by: Cursor <cursoragent@cursor.com>
The 2MB cap (matching the long-connection upload path) does not work for
the callback path: there the whole image is base64-embedded in an
AES-encrypted body returned on every poll. A ~1.5MB image (base64 ~2.1MB,
encrypted ~2.8MB) makes WeCom reject the finish packet and poll forever,
which also surfaces as a truncated text bubble and WeCom's own timeout
error. Cap well below that at 512KB so the finish packet is accepted.
Co-authored-by: Cursor <cursoragent@cursor.com>
Defer the callback stream finish after a text reply so a trailing
image-with-caption send (text first, image 0.3s later) can merge in
instead of closing the stream prematurely. Raise the callback inline
image cap from 512KB to 2MB to match the long-connection upload path.
Co-authored-by: Cursor <cursoragent@cursor.com>
In callback mode the image is base64-embedded in the stream finish reply and
the whole response is AES-encrypted and returned on every poll. A multi-MB
body is rejected/times out on WeCom's side, leaving the "···" bubble spinning
and the image never shown.
- Compress callback images to <=512KB (JPEG, resize if needed) instead of the
10MB the protocol nominally allows
- Fall back to the original image if compression fails, and log the final
base64 payload size for diagnosis
Co-authored-by: Cursor <cursoragent@cursor.com>
The streaming "···" bubble should only stop when the task actually completes
or the user cancels — not on an arbitrary timeout that would also steal the
response_url fallback's chance to deliver a late answer.
- On agent_cancelled, finalize the stream (finish=true, "🛑 已中止" if empty)
and schedule the response_url fallback so the bubble clears immediately when
a run is cancelled, even past the poll window
- Do not force-finish a still-running stream on a timer; let it keep spinning
until completion or cancel. Answers that finish after WeCom's ~6min poll
window are delivered via response_url instead
Co-authored-by: Cursor <cursoragent@cursor.com>
Handle agent replies that finish after WeCom stops polling the passive
stream (the poll window is ~6min from the user's message).
- Capture response_url from the message callback and, when a reply is
finalized but no poll picks it up within a short grace period, push it as
a one-shot active markdown reply (valid 1h, single use)
- Guard against double delivery via delivered/url_sent flags
- Embed public image URLs in the active markdown; note when a local image
can't be delivered post-timeout
- Append (instead of discarding) the unsupported-type notice for
file/voice/video replies so streamed text is preserved
- Quiet the per-poll debug log and log stream completion with content size
Co-authored-by: Cursor <cursoragent@cursor.com>
Support receiving WeCom smart-bot messages via encrypted HTTP callback in
addition to the existing WebSocket long connection. Disabled by default
(wecom_bot_callback=false).
- Add wecom_bot_callback / wecom_bot_token / wecom_bot_encoding_aes_key /
wecom_bot_port config keys
- Add WXBizJsonMsgCrypt-based crypto module for URL verification, callback
decryption and passive-reply encryption (receive_id empty for internal bots)
- Reply asynchronously via the official stream-refresh polling: register a
stream id on first reply, accumulate agent output into per-stream state, and
serve the latest content (text + image) on each poll until finish
- Fall back to EncodingAESKey for media decryption when callback bodies carry
no per-message aeskey
- Degrade unsupported passive replies (file/voice/video) to a text notice
- Expose the new fields in the Web console channel config
Co-authored-by: Cursor <cursoragent@cursor.com>
- Clear NOT_SUPPORT_REPLYTYPE on weixin, wecom_bot, dingtalk so TTS replies
are actually synthesized for these channels.
- Wire desire_rtype=VOICE in weixin and wecom_bot _compose_context so the
always_reply_voice / voice_reply_voice toggles take effect.
- DingTalk: send native sampleAudio (mediaId + duration). The media API
only accepts ogg/amr, so convert TTS mp3/wav to amr on the fly.
- WeCom Bot: send native voice msgtype via ws (respond + active push),
converting TTS audio to amr before upload.
- Weixin (ilink): no outbound voice item, deliver TTS as a file attachment.
- chat_channel: when a TEXT reply is converted to VOICE, stash original
text in context["voice_reply_text"] and send a text bubble before the
voice reply. Skipped for feishu_streamed and wechatcom_app, which
already render text alongside the voice.
