门店断网前提交了打印订单，请求超时，店员后来又取消了订单。网络恢复后，如果系统把未收到成功回复的请求全部重跑，打印机可能再次工作，已取消的订单也会重新出现。
成熟队列、订单状态和打印任务查询应先派上用场。只是刷新库存这类读取，丢弃旧请求再查一次通常就够了；有打印、扣款等实际影响的操作，不能用同一套重试办法处理。
可以让助手通过 EasyNet 调用订单系统的提交与查询操作，每次都携带稳定的业务任务编号。提供方返回受理状态及可查询编号，订单服务保存有效期、取消状态和已经发生的结果，不能只记网络是否通了。
重连时先查询这张单，而不是重新发起一张。如果打印已完成，只找回结果；如果订单已取消，就停止等待中的工作；如果无法确认打印机是否执行过，应进入人工核查，而不是把未知当成失败。
这要求打印系统能查任务，或者有明确的去重与对账办法。运行连接过期只说明这条连接不能继续使用，并不能决定订单是否作废。谁负责查明外部结果、多久转人工，需要提前约定。
测试时让打印完成但故意丢掉回复，再取消另一笔尚未执行的订单，最后恢复网络。看见第一笔结果被找回、第二笔没有重放，比看到所有请求都变成绿色更能说明恢复流程可靠。
- 01
网络中断
没有回复，不代表没印
- 02
查原订单
保留同一业务任务编号
- 03
按事实恢复
找回结果或转人工，不盲重放
为三种重连状态选择下一步
合成状态决策，不访问打印机，也不提供恰好一次保证；状态须来自真实业务查询。
本地示例 · python
jobs = {"print-1": "completed", "print-2": "cancelled", "print-3": "unknown"}
actions = {"completed": "retrieve-result", "cancelled": "do-not-run", "unknown": "investigate"}
plan = {job: actions[state] for job, state in jobs.items()}
assert "reprint" not in plan.values()
print(plan)预期结果：分别取回、停止、核查；没有一律重印。
接入时的检查项
- 已取消与过期任务在重连后不执行，仍有效任务可继续。
- 确认丢失的已完成任务通过业务记录识别，不造成第二次副作用。
- 无法确定的状态清楚显示为待核查，而不被统计成成功或安全失败。