任务恢复了，订单却执行两次：持久化工作流的边界

假设一条订单流程已经完成审核，下一步调用仓库接口创建出库单。仓库创建成功，回执却在网络中丢失。调用方等到超时，随后重启；恢复机制发现这一步没有完成记录，于是再次提交。若仓库把它当成新请求，同一订单就可能产生两张出库单。

这里没有假定持久化系统损坏。问题恰恰发生在它正常恢复工作的时候。

AWS在2026年3月发布的Lambda durable functions实践材料，介绍了通过检查点和重放保存流程进度的方式。当前官方幂等文档同时明确：步骤默认是至少一次执行；已经完成并保存结果的步骤可以直接复用结果，尚未完成的步骤仍可能重试。前一个能力有用，后一个条件不能省略。

回执丢了，完成记录也没有

把刚才的假设按先后排开，只有四个时点：

1. 工作流发出创建出库单的请求。

2. 仓库接受请求，产生业务结果。

3. 回执丢失，工作流没有保存该步骤的完成检查点。

4. 工作流恢复，再次尝试这个步骤。

关键缝隙在第二步与第三步之间。仓库的业务状态已经改变，工作流的记录却还不知道。恢复程序只看到自己的历史，不能从“我没有收到成功”推出“对方没有执行”。

图1｜假设场景的先后顺序：出库单已创建，完成检查点尚未保存，恢复后便可能重试。时间线不表示各阶段耗时相等。

检查点记录的是系统已经可靠保存的进度，并非整个业务世界的实时副本。除非外部操作与完成记录处在同一个可靠的原子提交范围内，否则不能仅靠持久化工作流消除这个不确定窗口。

也别把启动去重和步骤去重混为一谈。用同一个执行名称防止订单流程重复启动，可以挡住一类重复；它不会自动让流程内部的仓库接口变成幂等接口。键的有效范围、保留期限和重复请求的参数规则，也要按具体服务核对。

同一笔出库，要有同一个可核对的身份

较稳妥的方式，是在第一次调用前确定业务操作键，并让后续重试沿用。键可以由订单与本次合法发货动作共同标识，不能在每次尝试时重新生成，也不能让同一订单不同批次的合法发货误用同一个键。

执行方还必须兑现这个键的含义：相同键、相同业务参数到达时，复用或返回原操作的状态；同一个键带来不同货物或数量时，应拒绝冲突，而不是悄悄当成同一请求。去重记录与业务结果的关系必须可靠，两个并发请求也不能同时穿过去重检查。

仅在调用方数据库里加一个“已发送”标志，通常不够。先打标再调用，打标后崩溃可能使操作永远漏做；先调用再打标，操作成功后崩溃又回到了重复窗口。把两个语句换个顺序，并没有使它们变成同一件原子操作。

若出库单创建和去重记录由同一个数据库事务处理，可以在那里建立一致的约束；若调用的是第三方仓库，就需要依赖它提供的幂等契约或其他可验证机制。工作流引擎无法替外部服务补出一项它根本不支持的保证。

还要看时间。工作流可能等待很久才重试，而执行方的去重记录可能已经过期。首次成功保留一天、流程隔几天又提交，并不能靠“键还是原来的键”证明安全。自动重试窗口与去重、查询记录的保留窗口应互相匹配，超出后需要另一条处理路径。

有些超时，应当停在“结果待核对”

当接口能够按业务键查询，恢复后可以先核对原操作。确认成功就继续；明确失败或明确未受理，再按约定决定是否提交。查询暂时为空却不一定是未执行：可能只是查询副本尚未更新，或者原请求仍在处理中。查询的一致性与状态含义也属于接口契约。

如果既没有可靠幂等机制，也没有可靠结果查询，架构就面临真实取舍。继续重试可能重复出库，停止重试可能漏发。对于已经可能触发实物发运的操作，把订单进入待核对队列、限制后续动作并安排人工确认，往往比自动猜测结果更可控。

补偿也不是时间倒流。创建的出库单尚未执行时，也许还能取消；包裹已经交给承运人后，撤销单据并不能让包裹自动回到货架。能补偿到什么状态、谁确认完成、失败时如何继续，都要根据业务动作本身决定。

图2｜包裹交给承运人后，撤销电子单据不能让实物自动返回。场景示意用于解释补偿边界，不是实际事故照片。

这里增加了人工成本，也可能延长交付时间。应把这类例外数量和最长停留时间纳入运行指标，否则主流程显示成功率很高，真正的不确定订单却堆在角落里。

恢复测试，故障要打在缝隙上

正常跑完一遍，只证明正常路径可用。更有价值的测试是：让外部操作已经成功，再丢弃回执；在完成检查点写入前终止执行；让重复请求同时到达；让查询短暂返回旧状态。验收同时核对工作流状态和仓库里的真实业务结果，不能只看重试次数。

图3｜验收看两边的状态。流程结束而业务重复，或流程等待而业务已完成，都需要继续核对；图中状态为测试分类。

长时间运行还会遇到代码变化。AWS的调用文档建议生产使用不可变的编号版本，在途执行继续使用其原有版本。一般而言，重放需要稳定的执行语义；流程中依赖时间、随机数或外部读取的决定，也应遵循所用框架的持久化规则，不能恢复一次就走出另一条未经设计的分支。

如果恢复测试只能证明“任务最终结束”，再补一项验收：同一个业务动作到底产生了几次结果，无法确认时是否停在可处置的状态。流程进度有人保存以后，架构师仍要为外部世界已经发生的事情找到确认办法。