S39：重复消息、Partial Success、Timeout 与人工审批

内容类型：预习教材（不代表已完成）
日期：2026-12-31
阶段：P2 · AI Systems Engineering 90
总路线：Day 129 / 360
周次：W6 · Agent Runtime & Durable Workflow
节奏：周四案例与连接
状态：教材已备；学习未完成
标签：duplicate、partial-success、timeout、approval、reconciliation

一句话定义

分布式业务流程最危险的不是显式失败，而是“部分已发生、部分未知”；runtime 必须把重复、超时和人工决定建模为可追踪状态。

学习目标

1. 能区分 transport success、tool success、business success 与最终确认。
2. 理解 timeout 表示等待期限耗尽，不证明下游没有执行。
3. 为重复、部分成功和审批超时选择 retry、query、compensate、reconcile 或 escalate。
4. 能画一张状态→处理方式表并说明残余风险。

核心知识

• 消息队列常提供 at-least-once 投递，消费者必须假设重复；去重只能在明确作用域内实现。
• Partial success 可能发生在批量动作内部，也可能发生在跨系统步骤之间。必须保存逐项结果，不能把整体标成一个失败后全量重试。
• Timeout 有 client timeout、queue timeout、activity timeout、approval deadline 等不同层。上层超时不应自动取消已进入下游的副作用。
• Retry 适合临时且可安全重复的动作；query 用于未知状态；compensation 用于有明确反向业务动作的已知成功；reconciliation 用权威事实修复差异；escalation 处理系统无法自动决定的风险。
• 人工审批也可能重复、迟到或冲突，需要决策 ID、状态版本、权限和时间证据。

机制与推导

可建立处理矩阵：

未发送且失败       -> retry
已发送、状态未知   -> query / reconcile，不盲重试
部分条目成功       -> 保存逐项结果，只处理未成功项
已成功且可逆       -> 必要时 compensation
审批逾期           -> reassign / escalate / expire
重复确认事件       -> dedupe 后返回既有结果

若批量大小为 (n)，成功集合 (S)、失败集合 (F)、未知集合 (U)，恢复操作必须针对集合而不是一个全局布尔值：

[ S\cup F\cup U = {1...n},\quad S,F,U;互斥 ]

对 U 重试会有重复风险；应先查询。对 S 全量补偿也可能伤害合法结果。状态集合让处理决策可解释。

最小练习或观察步骤

1. 选择“向三个内部系统同步案件标签”的合成案例。
2. 设置 A 成功、B 明确失败、C 请求超时，分别放入 S/F/U。
3. 为每项选择 retry、query、compensate、reconcile 或 escalate，并写原因。
4. 加入一个晚到的人工拒绝事件，判断当前 stateVersion 是否仍接受。
5. 画从 workflow 到三个系统和 human queue 的序列图，标明未知窗口。
6. 不发真实请求；案例分析本身就是本日完整学习方式。

常见误区与边界

• 看到 timeout 就认为下游未执行，然后立即重试不可逆动作。
• 批量一项失败就全量重放，重复已成功项目。
• 用 compensation 掩盖原始效果，删除审计历史。
• 将迟到的审批静默丢弃，不告诉审批者状态已变化。
• 把 DLQ 当作自动恢复；DLQ 只是隔离待处理消息。
• 不需要追求理论 exactly-once；重点是让未知状态和处理责任显式化。

系统 / 金融 / Web3 场景连接

支付批量退款中，一部分银行通道接受、一部分拒绝、一部分超时，全量重试可能重复退款。AML 案件同步也需逐系统对账。链上交易广播超时后，节点可能已经接收；应按交易哈希或 nonce 查询，而不是立刻构造第二笔经济效果相同的交易。

自检问题

1. timeout 为什么不是失败证明？
2. S/F/U 三集合怎样改变恢复动作？
3. compensation 与 reconciliation 有什么区别？
4. 迟到审批事件应检查哪些条件？

专业课程对齐

• 阅读 MIT 6.5840 Distributed Systems 的 RPC、fault tolerance 与 consistency 主题，重点理解请求/响应丢失如何制造“执行与否未知”。
• 阅读 Temporal 官方文档 中 Activity timeout、retry 与 cancellation 概念，比较不同 timeout 的语义，不把默认重试照搬到不可逆业务动作。
• 阅读 Google SRE 资源 的 incident management 与 distributed systems 相关章节入口，把 reconcile 和人工升级放入实际运营责任链。

深入学习提示

阅读时用三种失败注入做思想实验：请求前断、下游提交后断、响应返回后上层断。每种情况下列出可见证据和权威查询点。不要急着给所有情况统一重试策略；能识别未知状态往往比自动化更多更重要。

学后填写区

• 选择的合成案例：
• S / F / U 状态：
• 每类恢复动作及理由：
• 一项残余风险：
• 尚未理解的问题：