bug(im-x): 已连接 X 账号提及 @askmycindy 后没有回复

[nanaco666]

用户原始反馈 / Original report

我在 X 刚刚 @askmycindy，但是没回复。

用户指的是 Cindy「设置 → IM 机器人」中的官方 X 通道，不是 X Manager 插件。

问题描述 / What happened

IM 机器人页面显示 X 通道已启用并连接：

• 关联账号：@making_cindy
• Cindy bot：@askmycindy
• 页面状态：已连接

用户发布了以下公开帖子：

• 帖子链接：https://x.com/making_cindy/status/2088096837366698108
• 发布时间：2026-08-14 10:54:15（UTC+8）
• 帖子正文：@askmycindy 记录这个问题，给出优雅的产品设计解决方案

帖子中的 @askmycindy 是有效 mention，但帖子发布后没有收到 bot 回复，Cindy 中也没有出现对应任务。

期望行为 / Expected behavior

已连接的 X 账号公开提及 @askmycindy 并给出任务后：

1. 任务应派发到当前绑定的 Cindy 设备；
2. Cindy 应创建并执行对应任务；
3. 执行结果应作为 X 回帖返回。

实际行为 / Actual behavior

• X 帖子发布成功且公开可见；
• @askmycindy 没有回复；
• Cindy 没有收到或创建对应任务；
• 用户侧没有任何已接收、处理中或失败提示。

环境 / Environment

• Cindy 版本：0.1.46
• 平台：macOS
• 安装方式：正式安装版
• 功能入口：设置 → IM 机器人 → X
• 绑定关系：@making_cindy → @askmycindy

初步排查证据 / Initial evidence

• cindy-x-hook 于 2026-08-14 10:43:13（UTC+8）完成握手，早于发帖约 11 分钟；
• 发帖后客户端没有收到任何 provider=x 的 task.dispatch；
• 客户端日志和请求账本中均不存在 tweet ID 2088096837366698108；
• 客户端于 11:17:58 再次完成 X hook 握手后，仍没有收到该任务的补投；
• 同一绑定在 2026-08-06 至 2026-08-07 曾成功接收过 X 任务。

目前只能确认该帖子没有派发到 Desktop；具体原因待进一步排查。

复现步骤 / Steps to reproduce

1. 在 Cindy 的「设置 → IM 机器人 → X」确认账号已连接；
2. 使用已关联的 X 账号发布包含 @askmycindy 的公开任务帖；
3. 等待任务进入 Cindy 并观察 X 回复；
4. 实际没有收到任务，也没有 bot 回复。

[dash-s-cindy]

判断

这次需要立即处理：公开 mention 没有进入 Cindy，用户在“账号已绑定、页面显示已连接”的情况下经历了完整的静默失败。当前证据可以把故障边界收窄到 Desktop 之前，但还不能把根因定为 X Activity API、游标、过滤、去重或服务端入队中的任何一项。

进一步检查发现，当前绿色“已连接”表达的是 Desktop 与 x-hook 服务之间已完成 WebSocket 握手和能力协商，并不等价于上游 X mention 摄取链路健康。因此这里同时存在两项需要推进的工作：恢复这条漏掉的用户任务，以及补齐服务端诊断、恢复和健康状态能力。

行动

1. 先完成本次用户闭环：以 tweet ID 2088096837366698108 建立人工接管记录，并在服务端建立 tweet-ID 级幂等占位或等价抑制记录后补跑原任务。X 渠道既定方案以 like 作为接收 ACK；不建议先发一条公开确认、完成后再发第二条，以免违背单次交互只发一条公开回复的既有产品约束。最终结果应在原帖下最多回复一次；如需人工说明进度，优先使用用户已有的非公开联系渠道。
2. 按事件 ID 排查服务端全链路：依次查询 XAA 原始交付、事件持久 inbox、过滤判定、绑定归属、任务/outbox、dispatch requestId 和 Desktop ACK，并清点同一异常时间窗内的其他 mention。现阶段没有证据支持要求用户重绑或重发。
3. 拆分服务端和客户端交付：服务端负责按 tweet URL/ID 查询、幂等补投/人工接管、摄取停滞告警及安全时间窗内的自动对账；协议提供结构化摄取健康快照后，客户端再分别展示“账号已绑定”“Desktop 已连接”“X 摄取健康/降级/未知”。

已确认的代码事实

基于 origin/main@4b5a0243a532f7922fa4832427b1e27ffa8a5a36：

• apps/desktop/src/main/hook-control/manager.ts 已注册完整的 X provider lane。providerForTaskDispatch() 只在 source.im === 'x' 且 externalKey 使用 x: 前缀时接受并路由任务；如果服务端已经生成合法的 task.dispatch，Desktop 具备接收和执行能力。
• 同文件的 laneView() 仅从本地 transport、welcome capability 和 binding 生成 connected / connecting / error 等状态。
• apps/desktop/src/shared/hookControlIpc.ts 中的 ProviderHookView 只有连接、能力、绑定和默认工作目录字段，没有 XAA 最近成功时间、摄取游标、最近事件、积压或连续错误。
• apps/desktop/src/renderer/components/settings/HookConnectionsSection.tsx 直接使用上述 transport 状态渲染 X 卡徽章。因此绿色“已连接”可以准确说明 Desktop WebSocket 在线，却不能证明整条 X 摄取链路健康。
• apps/desktop/src/main/hook-control/requestLedger.ts 已有 (connectionId, requestId) 级持久终态账本；dispatcher.ts 会在服务端重投同一 requestId 时回放 ACK/终态，避免再次运行 Agent。
• dispatcher.ts 还已支持协商式 turn.delivery 回执、断线重发及跨重启的终态 outbox。这些都是 task.dispatch 到达 Desktop 之后的可靠性保护。

本次客户端日志和账本中均不存在该 tweet ID，也没有对应 task.dispatch。因此上述下游机制不是本次故障的既有修复，也无法说明事件在 Desktop 之前卡在哪一步。

建议的恢复边界

1. 服务端以 tweet ID 建立唯一事件记录

实时摄取、自动对账和人工补投应竞争同一条事件记录及原子认领状态，而不是各自创建互不关联的普通任务。建议至少记录：

• tweet ID、URL、作者和 binding ID；
• XAA 是否收到及原始事件时间；
• 过滤结果与结构化原因；
• inbox/outbox 状态；
• dispatch requestId、Desktop ACK 和任务终态；
• 公开回复状态；
• 人工接管人、时间和审计信息。

Desktop 继续以 requestId 保证下游重投不重跑；服务端以 tweet ID 保证上游摄取、对账和人工恢复互斥。无需在客户端再造一套 tweet-ID 执行幂等。

2. 目标采用 effectively-once

“自动补投、人工补跑和实时摄取并发时最多执行一次、最多公开回复一次”需要覆盖两个独立状态：Agent 执行认领和公开回复发布。

公开回复遇到网络结果不确定时，应先进入“待核验”状态，查询实际发布结果后再决定是否重试，不能把简单重试描述成严格 exactly-once。更准确的验收目标是 effectively-once。

如果当前运营入口还不能先建立服务端幂等占位，人工执行仍可作为紧急补偿，但必须先把该 tweet 标记为“人工接管”，并在恢复摄取或批量补投前将接管清单加入抑制规则，否则无法承诺不会重复执行或重复回复。

3. 摄取健康应由服务端提供

建议健康快照至少包含：

• XAA stream/webhook 最近成功或心跳时间；
• 最近事件时间；
• 最近一次 backfill/游标推进时间；
• inbox/outbox 最老待处理年龄及积压；
• 连续错误和当前故障范围；
• 快照生成时间与有效期。

协议应下发结构化的 healthy / degraded / unknown，快照过期时回到 unknown。客户端不能仅凭“最近没有收到任务”自行判断摄取停滞，因为正常低流量和上游故障在本地不可区分。

连接状态仍应保留并明确命名为“Desktop 连接”，避免把绑定、WebSocket 和上游摄取健康合成一个绿色状态。

本次服务端排查应回答的问题

1. XAA 是否交付了 2088096837366698108？
2. 若已交付，是否成功写入持久 inbox？
3. 是否因事件类型、回复形态、作者、binding 或安全规则被过滤？过滤原因是否有结构化记录？
4. 是否生成任务/outbox，是否曾被 worker 认领但未完成派发？
5. 若 XAA 未交付，异常窗口、订阅状态、重连/backfill 结果和同窗遗漏范围是什么？
6. 11:17:58 Desktop 重连后没有补投，是因为服务端不存在该事件、事件已进入终态，还是恢复机制没有覆盖该阶段？

在这些记录拿到前，不宜把根因写成“游标错误”“去重误杀”或笼统的“X 消息延迟”。对用户可以准确说明：“这条帖子没有自动进入 Cindy，已人工接管。”

验证建议

• 在 XAA 接收、inbox 写入、过滤、outbox 入队和 dispatch 各阶段分别注入失败，确认按 tweet ID 能定位唯一停点。
• 并发触发实时摄取、自动对账和人工补投，断言只生成一个可执行任务。
• 在 Desktop ACK 前后分别断网、重启和重投，验证现有 requestId 账本回放且不重跑 Agent。
• 覆盖回复发布成功、明确失败和网络结果不确定三种状态，确认不会盲目重复公开回复。
• 保持 Desktop WebSocket 在线但停止 XAA 消费，确认服务端告警、客户端显示“摄取降级”，同时继续如实显示“Desktop 已连接”。
• 恢复后执行安全时间窗内的 backfill/对账，并确认已人工接管的 tweet 不会再次执行。
• 验证正常摄取后使用 like 作为接收 ACK，最终结果只产生一条公开回复。

相关记录

• feat: X (Twitter) 机器人渠道 —— @提及派发任务并读取 thread 上下文(调研结论与实施计划) #691：确定了 X 采用 always-on 服务端 XAA 摄取、服务端扇出和 like ACK 的产品与架构方向；摄取健康、遗漏恢复和接收反馈的主要责任边界在服务端。
• feat(desktop): 接线 X (Twitter) hook provider #1230：已合并 X provider 的 Desktop 接线、绑定 UI、任务路由和灰度入口；该 PR 明确不包含 x-hook-server 部署、X 外部前置或服务端运维能力，因此不是本次漏收的既有修复。
• fix(desktop): X 回复收到服务端确认前持续重试 #1794：已合并 Desktop 结果在收到服务端 turn.delivery 回执前持续重试的修复；它解决的是“任务已执行、结果回传可能丢失”，不覆盖本次“任务从未到达 Desktop”的阶段。