Webhook 重试处理是一个状态管理问题。即使接收方完成了一些工作，发送方也可能会在超时后重新发送。如果每次尝试都会创建一个新票证或重复更改，则集成会将普通的网络故障放大为操作事件。
区分交付尝试和业务影响
使用提供商的记录身份和订阅或租户范围定义交付密钥。单独定义业务效果，例如更新一项现有的身份验证结果。多个有效事件可能与同一发现合理地相关，而重复传递一个事件不应两次应用其效果。
GitHub 的 webhook 指南 表示请求的重新交付保留 X-GitHub-Delivery。它还建议在十秒内响应 2XX 并考虑异步处理。将这些视为 GitHub 特定的记录行为。不要承诺每个提供商都会自动重试或使用相同的超时；确认其实际发货政策及误发货恢复路线。
在右边界处确认
首先验证事件，然后在确认成功之前持久记录已接受的工作。从队列中处理昂贵的工作。如果持久接受失败，不要仅仅因为解析成功就发送成功响应。相反，当提供商需要快速响应时，不要保持连接打开，直到长时间的下游调查完成。
使用排队、处理、重试挂起、完成和死信等状态。跟踪尝试计数和下次重试时间。工作线程崩溃可能会导致处理请求被放弃，因此请定义安全租约或恢复规则。使用数据库约束或事务来保护唯一性和状态转换，而不是容易受到并发交付影响的先读后写检查。
设计可重试的效果
对于外部调用，请使用受支持的幂等性密钥或可用的稳定目标身份。当超时导致结果不确定时，请在重复副作用之前阅读或协调目标。如果下游 API 无法提供幂等性，请记录残留的重复风险并添加补偿审核路径。
假设已验证的传递已持久排队，但其成功响应丢失。稍后请求的重新传递应该找到相同的传递状态，而不是仅仅因为另一个 HTTP 请求到达而创建第二个票证。另外，假设工作人员调用票证 API，并在该 API 创建票证后超时。队列的重复数据删除本身无法解决下游的不确定性：在重复创建之前检查目标或使用其支持的幂等性密钥。
这些是假设的故障路径，而不是执行队列、虚拟时钟测试或一次性保证。使用实际存储和下游合约测试并发重复、工作中断、废弃的处理租赁和有限耗尽。死信项目应保留安全证据，并在其原因得到纠正后需要受控重播，而不是默默地重置尝试计数。
关闭疲惫工作的循环
使用带有退避和适用速率限制信号的有界重试。 GitHub REST 最佳实践 解释该 API 的速率限制感知行为；将实际的下游服务合同应用于生产。将反复失败的项目移至受控的死信队列，并用安全证据和下一步措施提醒负责的操作员。
将可重试的传输错误与永久架构或授权失败分开。无限期地重放未经授权的请求不会修复其权限。保留足够的身份和结果证据来解释每个事件的最终状态，并在纠正后提供经过深思熟虑的操作员重播程序。监视最旧的排队工作、重试耗尽和未解决的结果，而不仅仅是成功的 HTTP 响应的计数。此处没有演示实时提供商重试行为或EmailAuth功能。