openclaw - 💡(How to fix) Fix openclaw-weixin proactive sends can return success while user sees 请稍后再试 / missing chunks

Summary

openclaw-weixin proactive/direct sends can still be reported as successful by OpenClaw while the Weixin user receives either nothing or a generic "请稍后再试" fallback message.

This occurs even after the sender has a valid cached contextToken, and even when short probe messages are delivered successfully. Longer messages and/or rapid multi-part sends can fail at the user-visible layer while OpenClaw still returns success + a local messageId.

This looks related to, but not fully covered by:

• #52153 — proactive sends require contextToken
• #52391 — proactive sends can be marked delivered even when the user receives nothing
• #78376 — runtime isolation / Content-Length compatibility issues

Environment

• OpenClaw gateway: 2026.5.6 runtime observed in logs
• Channel: openclaw-weixin
• Plugin: @tencent-weixin/openclaw-weixin
• Direct target shape: <user>@im.wechat
• Gateway mode: systemd user service on Linux

Observed behavior

1. Missing contextToken causes false-positive delivery

A cron/proactive send produced:

sendWeixinOutbound: contextToken missing for to=<user>@im.wechat, sending without context
sendMessageWeixin: contextToken missing for to=<user>@im.wechat, sending without context
✅ Sent via openclaw-weixin. Message ID: openclaw-weixin:...

The user did not receive the message.

A local guard patch changed this to lazy-restore persisted context tokens and fail closed if still missing. That fixed the no-context false-positive path.

2. Valid contextToken + short messages can work

After a user sent an inbound Weixin message, the plugin persisted a token under:

~/.openclaw/openclaw-weixin/accounts/<accountId>.context-tokens.json

A short plain text probe (~237 bytes) and a short Markdown/list probe (~156 bytes) were both received by the user. Gateway logs showed:

restoreContextTokens: restored 1 tokens for account=<accountId>
✅ Sent via openclaw-weixin. Message ID: openclaw-weixin:...

3. Longer proactive text fails user-visible delivery while OpenClaw reports success

A Daily News style message (~2890 bytes / ~1462 chars) was sent as one text item.

OpenClaw returned success:

✅ Sent via openclaw-weixin. Message ID: openclaw-weixin:1778220614987-39855673

Gateway logs showed token restore and no local error:

resolveOutboundAccountId: single account, using <accountId>
restoreContextTokens: restored 1 tokens for account=<accountId>
✅ Sent via openclaw-weixin. Message ID: ...

But the Weixin user did not receive the正文. Instead the user saw a generic message like:

请稍后再试

4. Smaller chunks improve but do not fully solve delivery

The same payload was split to 900-byte chunks. Chunks 2/3/4 were received, but chunk 1 still produced 请稍后再试.

Then the script was changed to line-preserving ~600-byte chunks. The message was split into 6 parts. The user reported receiving only parts 2 and 3; other parts were missing or produced fallback behavior.

This suggests not only a max text item size issue, but also possible rate/frequency, content, or downstream API semantics issues.

Expected behavior

OpenClaw / the plugin should not report proactive Weixin delivery as final delivered / success unless the downstream API confirms actual user-visible acceptance.

At minimum:

1. If contextToken is required, no-context sends should fail closed before calling sendmessage.
2. If the Tencent/iLink API returns 200 + {} or an otherwise ambiguous response, OpenClaw should treat the delivery status as accepted / unknown, not final delivered.
3. The plugin should expose and document safe text item limits and rate limits for proactive/direct sends.
4. For multi-part sends, the plugin or core should provide throttling / retry / delivery verification semantics.
5. If the downstream service returns or triggers a user-visible fallback such as 请稍后再试, the plugin should surface that as an error if detectable.

Actual behavior

• CLI/core returns success and a messageId.
• The messageId appears to be locally generated client id, not a downstream delivery id.
• User-visible delivery can fail or show 请稍后再试.
• Cron/automation can therefore mark Daily News / announcements as sent even when the user did not receive the intended content.

Reproduction outline

1. Ensure the target Weixin user has recently sent an inbound message so a contextToken exists.
2. Send a short plain text proactive message: it may succeed and be visible.
3. Send a ~2.9KB text/Markdown message via:

openclaw message send --channel openclaw-weixin --target '<user>@im.wechat' --message "<long text>"

or through a wrapper using the same channel.

1. Observe OpenClaw success + messageId.
2. Observe the user receives either no正文 or 请稍后再试.
3. Split into smaller chunks and send quickly; some chunks may arrive while others fail, despite all CLI calls returning success.

Local mitigation attempted

• Lazy restore contextToken from persisted token file before proactive sends.
• Fail closed if no token exists.
• Reduce text chunks from 6000 bytes to 600 bytes.
• Add configurable inter-part delay (OPENCLAW_WEIXIN_SEND_INTERVAL_SECONDS, default 1s).

These mitigations reduce one failure mode but do not solve final user-visible delivery semantics.

Suggested fix direction

• Treat Weixin proactive delivery as non-final unless a real downstream delivery acknowledgment exists.
• Require context token or route to an officially supported proactive mechanism (template/customer-service message) when outside reply context.
• Add plugin-side constraints for text payload size and send rate.
• Return structured delivery status: attempted, accepted, unknown, delivered, failed instead of always mapping no-throw to delivered.
• Optionally expose raw sendmessage response / error body under debug logs so callers can distinguish API accepted from user-visible success.