Qoder 0.4.3 眼镜端任务执行成功但收不到回执

现象

在夸克 S1 眼镜（千问眼镜产品线）上通过 Qoder 下发任务后，桌面端确实执行并成功完成了任务，但眼镜端收不到任务完成的回执。多次发起新会话后现象依旧。

环境

核心矛盾：执行成功，出站同步失败

failureCode 分布：

决定性证据：history_anchor 未持久化

rc_ingress_bindings：

rc_history_sync：

唯一同步成功的会话，是唯一 history_anchor 非空的会话。

故障持续恶化（同一会话三次采样）

重试不收敛，缺口单调扩大。

推断的因果链

history_anchor = NULL（未持久化）
  → 无法确立时间线顺序基准
  → attempted_revision 持续超前 revision（4→8→12→36）
  → 服务端返回 TIMELINE_ORDER_CONFLICT
  → 客户端无限重试（69 / 64 次不收敛）
  → 继发业务级 RateLimit 与 ARTIFACT_READ_FAILED
  → 回执永远无法送达眼镜端

anchor 是本地数据，非服务端下发

已验证 e45961ef-3384-4d96-8125-7869aae74e1e 存在于本地 rc_ingress_timeline.uuid（position 0000000031）。其位置规律为该轮次结束标记之前最后一条 chatcmpl-* 消息：

成功会话 f0e85105：30=chatcmpl 【31=chatcmpl ← ANCHOR】 32=普通 33=普通 33.000…1=desktop-end-turn 34=result
失败会话 4781d3fd：261=chatcmpl【262=chatcmpl ← 候选】 263=普通 263.000…1=desktop-end-turn 264=result

结构完全对应，故判断属客户端持久化缺陷。

入站方向健康（故障纯在出站）

• chat_session_input_receipts：19 条，全部 dispatched，0 条 failed
• rc_ingress_timeline：810 行；三个会话 100% confirmed、0 discarded；9e5bf914 出现 1 unconfirmed + 1 discarded（新增退化）
• 输入状态 流转 received → accepted → started 正常，最新 sequence = 20138，与 cursor 一致

其他异常

以下四表均为 0 行，疑似相关状态机未初始化：
rc_channel_admissions、rc_ingress_lifecycle_cursors（有 FK 指向 rc_ingress_bindings，后者有 4 行）、rc_ingress_management、rc_ingress_environment_inbox

已排除的因素

网络／防火墙（定量排除）

• HTTP 状态码：200 × 79、204 × 1，零个 429 / 4xx / 5xx
• 全日志无 Retry-After、无 too many requests
• 失败同步耗时 210–306 ms → 快速应用层拒绝，非网络超时
• 监听端口仅 127.0.0.1:63133、127.0.0.1:63496（回环 IPC，无局域网监听）
• 对外连接：47.116.142.188:443、8.153.206.47:443；主机仅 openapi.qoder.com.cn、gateway.qoder.com.cn
• 无 mDNS / Bonjour / zeroconf / 设备配对痕迹
• Windows 防火墙三 profile 均 Enabled，DefaultOutboundAction = NotConfigured（默认放行出站），无 Qoder 阻止规则
• 无 proxy 环境变量；configAdvancedProxyMode: system、configAdvancedProxyURL: ""
• QCS SSE 两次断连均于 0.8–1.5 秒内自动重连；遥测 Reported 74/74 events

补充：RateLimit 并非 HTTP 层限流。所有响应均为 200/204，该码为包在 200 响应体内的业务级错误码，且不携带任何重试等待时间，客户端呈约 67–83 秒的规律重试节奏。

其他

• 客户端进程健康（PID 47824，13 进程存活，日志持续写入），12 轮次全部 success:true
• 设备受支持（官方文档：「夸克同学」是千问眼镜的系统唤醒词）
• 配置无可调项：app_settings 共 8 键，唯一相关的 remoteControl.enabled 已为 true，无 anchor / sync / retry / 离线模式相关项
• 无可用更新：官方更新日志止于 0.4.3（2026-09-26），客户端上报 server-hold-0.4.3、targetVersion: null；0.4.3 自身无 bug 修复记录

相关版本历史

Remote Control 同步问题在多个版本被反复修补，本故障疑为同家族残留：

• 0.2.2（09-09）「增强远程控制异常自动恢复，修复……跨端同步问题」
• 0.3.3（09-18）「支持自动同步最近 7 天内更新的本地会话历史」＋「修复……重新连接时旧消息可能被重复执行的问题」
• 0.4.2（09-24）「修复 Remote Control 中删除会话后未正确同步的问题」

希望官方确认的问题

1. history_anchor 在何种条件下会未被持久化？为何 4 个会话中仅 1 个写入成功？
2. anchor 为 NULL 时，客户端为何仍持续计算超前的 attempted_revision 并无限重试，而非中止并上报可诊断错误？
3. revision 中 SHA-256 的输入规范化方式为何？（本地尝试 34 种假设均无法复现已知良好值，含 Merkle 根、哈希链、XOR 折叠等）
4. rc_channel_admissions 等四表恒为 0 行是否符合预期？
5. 业务级 RateLimit 的阈值与窗口为何？是否由本故障的重试风暴触发？
6. 已卡死会话的历史是否可恢复？（4781d3fd 已重试 69 次，9e5bf914 64 次）

备注

诊断全程对本机日志与数据库只读访问（main.sqlite 以 mode=ro 打开），未修改任何配置、数据库、防火墙或程序文件。完整日志目录与数据库副本可按需提供。