增量同步应该能够在页面中途停止并重新启动，而不会丢失证据。困难的情况不是第一次成功下载。是存储后的超时、重启后的重复投递以及表观报告期结束后到达的报告。
定义身份单位
使用提供者记录的报告身份并保留其租户和报告者上下文。不应假设报告 ID 在客户或来源中具有全局唯一性。将源有效负载指纹与身份一起存储。相同的重复可以被视为重复；应通过记录的修订模型来调查或处理具有不同字节的相同身份。
RFC 9990 提供了结构和语义 汇总报告。单独保留原始报告期间和接收时间。收集器的增量水印不应默默地将历史评估期重新解释为到达时间戳。
一起提交数据和进度
获取有界页面，验证范围和模式，写入规范化数据及其来源，然后才推进检查点。更喜欢以原子方式提交数据和进度的事务。如果不可用，请设计具有稳定唯一性约束的重放。在记录持久之前保存的游标会创建一个丢失窗口。
假设收集器持久存储第一页，但在推进其进度标记之前崩溃。重新启动时，它可能会再次获取页面。适当范围的稳定身份约束应该避免添加精确的重复，同时允许提交下一页。如果进度标记在记录持久之前就已前进，则重新启动可能会完全跳过证据。这些是假设的故障状态，而不是执行的文件或数据库测试。
如果重复的身份以不同的源字节到达，请保留原始身份和冲突，以记录修订决策。更改的哈希是要调查的信号，而不是消息计数更改的证据：格式化或规范化也会影响字节。在批准的实施下测试实际存储事务、崩溃恢复和源字节比较；本指南不保证耐用性。
处理迟到而不声称确定性
当实际 API 支持重新查询到达时，使用有界重叠窗口，然后按身份进行重复数据删除。使用观察到的摄取延迟和操作需求来选择重叠。有限的重叠不能保证发现任意迟到的数据。添加定期全面对账或其他记录的回填机制并记录剩余的覆盖范围限制。
使修改与完全相同的副本区分开来。保留冲突时的两个哈希值，并防止不明原因的替换默默地更改已发布的客户报告。当接受有效的更正时，在新修订下重新计算受影响的摘要，并追溯到以前的结果。
根据真实服务合同恢复
遵守速率限制、重试后和特定于版本的分页。 GitHub 的 API 最佳实践 提供有限制的、体贴的请求行为的具体示例；他们没有定义身份验证供应商的配额。将 429 或暂时性故障视为在策略内暂停和重试的原因，而不是作为无限并行请求的许可。
监视最后一个成功的检查点、最旧的未处理到达、重试耗尽和冲突。具有卡住光标的健康 API 响应仍然是失败的同步。如果结果不明确，请在重试有副作用的步骤之前检查存储的身份和进度。保留源字节和先前的检查点，以便恢复以证据为主导。这里没有演示 API 调用、重试模拟或EmailAuth同步功能。 GitHub 的速率限制文档 注意它可能会返回 403 以及速率限制的 429；将记录的限制信号与永久授权拒绝区分开来，而不是为每种状态分配一种含义。