让重试安全且可以恢复

以下示例与示意结果由本站编写，用于说明方法，不是模型实测结果。

使用场景

发布请求超时，服务可能已接受操作。教学服务经过契约核验，能对同一操作键和相同载荷进行去重，并提供按键查询状态；本次键为 r42。你要恢复同一发布意图，而不是新建多次发布。

具体做法

提交前保存操作身份、精确载荷与当前状态。超时记录 unknown，先查询相同键的状态；只有接收端确实保障该键的幂等与并发规则、且仍在有效范围内，才按契约重提同一意图。已接受不等于健康，通过实际健康检查后才写 healthy。没有安全重试契约时保持未知并对账，不创建新键试探。

反例

r42 超时就不断用 r43、r44 重新 deploy，任何成功响应都标 healthy，不管原请求是否已经生效。

改进写法

按教学服务的已核验契约，提交前记录 r42 和精确发布载荷。超时先标 unknown，查询 r42；若已接受则继续状态核对，不创建新意图。允许安全重提时只复用 r42 与相同载荷，核对键有效期及并发保障。实际健康检查通过才从 submitted 进入 healthy；无法确定原效果或服务不保障重试时保留未知并请求对账。

为什么这样改

超时描述客户端没拿到确定答复，不说明外部效果没发生。稳定且由接收端执行的操作身份，把重复请求连回同一意图；显式状态又避免把接受、交付和健康混成成功。

如何验证

教学故障测试中，首次已接受但响应丢失，查询 r42 应找到同一操作；重复同键同载荷不得创建第二个版本。健康检查未运行时状态不能是 healthy。

核对实际去重效果与状态证据，不以“传了一个键”代替服务保障。本篇没有发布真实版本。

适用边界

操作重试键不同于实体自然键；同步实体还需目标租户范围内唯一性或 upsert。无收据不证明未交付，未知效果需对账。用户问题也一样：可能已展示就等待答案，只重试确认展示前失败的传输；预选项、沉默和时间流逝不是同意。