使用MS Graph修改邮件附件随机出现双附件问题技术求助

核心故障原因 #

1. 后端最终一致性同步延迟 #

MS Graph 服务端采用多副本分布式架构，DELETE https://graph.microsoft.com/v1.0/me/messages/{messageId}/attachments/{attachmentId} 接口返回204成功状态，仅代表删除请求已被服务端接收并写入主节点，不代表所有副本节点都完成了附件删除的状态同步。此时立即调用新增附件接口，请求可能路由到尚未完成删除同步的副本节点，最终两份操作的状态同步完成后，就会同时保留新旧两个附件，这是该随机故障的最高发诱因。

2. 附件ID匹配错误 #

如果待处理邮件存在多个同名smime.p7m附件，或者获取原始附件、调用删除接口两个步骤之间，邮件附件被其他操作修改过，会导致删除时使用的attachmentId与目标附件ID不匹配，相当于未正确删除原始附件，新增后就会出现重复。

3. 无校验的重试逻辑触发重复操作 #

如果客户端配置了超时自动重试规则，删除或新增请求出现响应超时、网络波动时，可能触发重复提交：例如删除请求实际执行成功但响应超时触发重试，或者新增请求重复提交，都会导致最终附件数量异常。

可落地的修复方案 #

• 删除附件接口返回成功后，不要立即发起新增请求，增加1~2秒的等待时间；如果附件体积超过1MB，建议将等待时间延长到3秒以上，预留足够的副本同步窗口。
• 增加状态校验逻辑：删除操作完成后，主动调用 GET https://graph.microsoft.com/v1.0/me/messages/{messageId}/attachments/{attachmentId} 接口，确认接口返回404（即附件确实被删除）之后，再发起新增附件的请求。
• 新增附件完成后，再拉取一次当前邮件的全量附件列表做兜底校验，如果发现存在多余的旧附件，自动执行二次删除操作，避免异常流出。
• 如果使用MS Graph SDK发起请求，可在删除后的查询请求中添加ConsistencyLevel: eventual请求头，确保查询到的是全局最新的附件状态。

内容的提问来源于stack exchange，提问作者RaniDevpr