[Bug] WeChat sendMessage can report success despite attachment failure; investigate Official Cloud image send

Client Type

Other — WeChat bot conversation on Official Cloud; inspected read-only with LobeHub CLI.

Operating System

macOS for CLI inspection. Recipient device OS was not verified.

Deployment Platform

Official Cloud (app.lobehub.com)

Version

Official Cloud build at 2026-09-09 03:54 UTC: unknown; please confirm the deployed revision. Inspection CLI: lh 0.0.48.

Browser

Not relevant to the outbound tool path; no browser-specific reproduction established.

What happened?

An agent called lobe-message.sendMessage with a text message and a JPEG attachment for the originating WeChat user. The tool returned:

Message sent to wechat:<redacted-recipient> (messageId: undefined)

The assistant then told the user: “发出去了 ✅ 蓝天版的图片已经直接发到微信里了，你往上翻一下应该能看到”. However, the stored tool result contains no attachment-specific delivery evidence. We have confirmed a real tool invocation, but have NOT independently confirmed that the image reached the recipient, or established that this particular image failed.

Source inspection identifies a concrete error-propagation gap: attachment failures can be returned by the helper and ignored by the service, allowing the tool to report unconditional success. This makes the assistant's delivery claim unreliable.

Observed timeline and correlation information

All times below are on 2026-09-09, UTC (China time = UTC+8):

These are message creation timestamps, not precise network request timestamps.

• Account-scoped conversation: https://app.lobehub.com/agent/agt_gtgHHBOS8NvS/tpc_v3PNYCgRiv7F (sharing was not enabled for this report).
• Tool-result message ID: msg_eazfA8GP5IlRl4GQJf
• Tool call ID: call_7e4f3e17d65c45a8b1835b19
• Operation ID from the invoking assistant message: op_1788925172676_agt_gtgHHBOS8NvS_tpc_v3PNYCgRiv7F_O0L5HllA
• Generated image was reported as 1000 × 750, 75,586 bytes by the sandbox.
• Raw recipient identifier, temporary image URL, signed source URLs and full conversation dump are intentionally omitted from this public report. Maintainers should be able to correlate the IDs above internally.

Read-only inspection used lh topic view tpc_v3PNYCgRiv7F -L 500 --json (61 messages) and lh message list. An actual lh bot message read attempt returned that readMessages is unsupported on WeChat, so CLI read-back cannot verify receipt. No message was resent during this investigation.

Source findings (local revision, not verified Official Cloud deployment)

Inspected clean repository revision: 0316ce6edb27df854f8026029638fe9724e01926.

1. sendWechatAttachments catches attachment download/upload/send failures and returns { failures, undelivered }. Some cases can also fall back to a text link.
2. WechatMessageService.sendMessage sends text first, awaits this helper, but discards its result and returns only channelId and platform.
3. The builtin tool runtime reports success: true and “Message sent” whenever the service resolves.

Therefore text success plus image failure can still be reported as overall success. messageId: undefined alone is not evidence of failure: the adapter simply does not supply this field.

How to reproduce it?

Observed user flow:

1. Send an image to a connected WeChat bot and ask the agent to edit it.
2. The agent obtains an externally hosted result image and invokes lobe-message.sendMessage with text plus an image attachment.
3. Observe the unconditional tool success message and the assistant's assertion of image delivery.

Suggested deterministic regression case for maintainers (not executed against production): make the attachment loader return no bytes, or make the media upload/send reject, while text sending succeeds. Verify whether the helper's failure result is lost at the service/tool boundary. No deterministic failure was injected in this investigation.

What it should be?

• Propagate per-attachment outcomes through the service and builtin tool result.
• Distinguish text accepted, image send accepted, link fallback, and attachment failed/undelivered.
• Do not claim full success when any requested attachment failed.
• Do not equate API acceptance with recipient receipt; represent unavailable receipt confirmation explicitly.
• Avoid rendering messageId: undefined as though it were a usable receipt.

Questions for Official Cloud maintainers

1. Which revision handled this operation, and does it contain the same ignored-result path?
2. Did the server fetch the actual JPEG bytes from the supplied URL? Please confirm HTTP status, content type and byte count, without publishing private URLs or payloads.
3. Did WeChat CDN upload succeed? What did the image sendmessage request return (ret, errcode, errmsg and any safe correlation ID)? Please distinguish this from the preceding text request.
4. Were any source-unavailable, upload-failed, undelivered or fallback outcomes logged and then discarded?
5. Can the available server/platform evidence establish image send acceptance or actual delivery? If receipt cannot be confirmed, please state that limit explicitly.
6. Can a regression test cover partial failure and ensure the agent receives a truthful structured result?

Additional Information

Related: #19313 concerns self-hosted LAN attachment fetch/SSRF allowlisting and explicitly leaves this separate error-propagation issue unaddressed. This report concerns the success-reporting boundary and an Official Cloud incident; it does not attribute this cloud incident to the LAN/SSRF cause.

Searched existing open/closed issues for WeChat attachment, sendMessage, success and undelivered reports before filing.