Microsoft Graph：发送邮件时收到Deleted变更通知的处理及原因咨询

通过Microsoft Graph API创建messages订阅以追踪邮件变更时，发送邮件过程中会收到该邮件的Created、Updated、Deleted多种变更通知，且通知无固定顺序，难以确定最终状态。对于Created和Updated通知，可通过存储并校验changeKey与lastModifiedDateTime来处理，但Deleted通知不含这些字段，无法区分是发送邮件时产生的无需关注的通知，还是邮件被删除时的有效通知。请问：

1. 发送邮件时收到Deleted通知是否属于预期情况？
2. 若是，该如何处理以确保状态正确？
3. 若不是，可能的原因是什么？

1. 是否属于预期情况？ #

是，这属于正常预期行为。Outlook/Exchange在发送邮件的内部流程中，会先将发件箱中的待发邮件临时移除（触发Deleted通知），完成发送后再在已发送文件夹生成对应的邮件记录（触发Created/Updated通知），这个中间环节会产生这类“临时”的Deleted通知。

2. 处理方案 #

• 延迟校验+主动查询：收到Deleted通知后，不要立即标记邮件为删除，而是延迟30-60秒（可根据业务场景调整时长），之后调用Microsoft Graph API的GET /me/messages/{messageId}或GET /me/mailFolders/sentitems/messages/{messageId}接口查询该邮件的实际状态。如果能查到邮件且它位于已发送文件夹，说明是发送流程产生的临时通知，直接忽略；如果多次查询都无法找到该邮件，再判定为真实删除。
• 关联同ID通知：所有变更通知都会包含邮件的id字段，将同一个id的所有通知关联起来。如果在收到Deleted通知的短时间内，收到了该ID对应的Created/Updated通知，且邮件处于已发送状态，则直接忽略这个Deleted通知。
• 按文件夹过滤：如果你的订阅范围是全局的/me/messages，可以在处理通知时先判断邮件所在的文件夹ID。发送流程产生的Deleted通知通常来自发件箱，而真实删除的通知可能来自收件箱、已发送等其他文件夹（可根据自身业务需求调整过滤逻辑）。

3. 非预期情况的可能原因 #

• 订阅范围配置错误：如果误将草稿箱纳入订阅范围，发送邮件时草稿被删除会触发Deleted通知。若业务不需要追踪草稿，应调整订阅路径为指定文件夹（如/me/mailFolders/inbox/messages），而非全局的/me/messages。
• 服务端临时同步异常：极少数情况下，Graph API的服务端流程同步延迟会产生异常通知，这种情况可通过多次主动查询邮件状态来排除，确认多次查询都无法找到邮件后再判定为删除。

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