【Bug】微信 Bot 桥回信失败（iLink /sendmessage "prepare failed"）导致同一条用户消息被无限重复注入会话

[seyrs1985]

使用环境

• OS: Windows 10.0.19045 x64
• ZCode 桌面版: 3.14.3
• 触发面: 微信 Bot 桥（provider=weixin，iLink 通道）

现象

一条用户从手机微信发给 bot 的普通文本消息，被重复注入同一个桌面会话 8+ 次，间隔约 2 分钟，持续数小时；桌面会话被连续刷屏产生多轮完整模型回合。当日该消息的 provider callback 日志累计 927 条（每 5-6 秒一条）。

复现步骤

1. 桌面版绑定微信 bot，桌面会话空闲
2. 手机微信向 bot 发送一条文本消息
3. 桥将消息注入会话、助手产生回复；若回信外发失败（见下），该消息无法确认
4. 观察：约每 2 分钟同一条消息被重新注入一次，不停止

证据链（脱敏日志摘录）

1. 外发全断：当日 698 次失败、0 次成功（前一日仅 12 次失败），当日 00:40 起持续：

[bots][trace:***] bot task stream event failed task=sess_****: Weixin iLink /sendmessage failed: prepare failed

2. 同一条消息反复回调（每 5-6 秒）：

[bots] provider callback provider=weixin bot=bot-**** user=<openid> text=<同一中文消息>

3. 会话侧每次注入都是新行（本地库 session_input 表）：delivery 在 startNow/queue 间切换、status=promoted、序列号递增——非同一行重放，而是消息源被反复重新提交
4. 轮询游标未推进：bot-state.v3.json 的 weixinGetUpdatesBuf base64 解码始终指向同一条 msgid

根因分析

外发 /sendmessage 持续 prepare failed（错误无内部细节）→ 助手回复无法送达微信 → 该 update 永远无法 ack → getUpdates 轮询游标卡死 → 每 ~5s 重拉到同一条消息 → 桥在会话空闲时再次注入，形成无限循环。链路缺少重试上限/死信机制。

影响

• 桌面会话被刷屏：每 2 分钟一个完整模型回合，持续数小时，产生大量无效模型调用
• 微信侧全天收不到 bot 任何回复（含自动化任务例行消息），且事后不补发

建议修复

1. prepare failed 输出具体原因（疑似凭证/token 过期类，某日 00:40 起全断、跨版本 3.12.3-3.14.1 均观察到桥链路问题）
2. 游标推进保护：消息已投递到会话但回信失败时，重试 N 次后应 ack 跳过或落死信，避免无限重注入
3. 同一 msgid 注入同一会话设次数上限（如 3 次）
4. 文档说明外发通道断开时的用户侧恢复路径（重登 bot 后卡住消息是否自动补投一次）

临时缓解

• 桌面端按停止键仅能拦下当次注入
• 停用微信通道可立即止血
• 重新登录 bot 后若外发恢复，卡住消息会被处理一次、游标推进、风暴自停

与 #697 / #741（Submission 模型解析）同属微信桥链路，但为不同故障点。完整日志可按需提供。

[github-actions]

👋 感谢你的反馈，我们已经收到。

• 维护者看到后会尽快回复你。
• 状态保持为 status: 待评估，你可以随时补充信息。
• 信息不全时我们会打上 needs: 更多信息 标签并 @ 你。

---

👋 Thanks — we've received your issue.

• A maintainer will get back to you as soon as we can.
• Status stays at status: 待评估 (Triage); feel free to add context.
• If we need more details, we'll add needs: 更多信息 and ping you.

[seyrs1985]

作者说明：本 issue 曾于 2026-09-28 由作者主动撤回（当时担心与作者其他公开仓库产生关联曝光，故清空内容并请求删除）。

现相关顾虑已消除（个人仓库已全部转为私有），作者恢复原标题与原正文并重新提交，内容与撤回前完全一致。此前"请管理员协助删除"的请求作废，请照常评估。抱歉给分诊带来困扰。

---

Author's note: this issue was withdrawn by the author on 2026-09-28 out of privacy concerns (association with the author's then-public repos). Those repos are now private, so the original title and body have been restored verbatim and the issue is reopened. The earlier deletion request is void — please triage as normal.