Microsoft Graph API重复发送消息资源created通知问题咨询

我针对Microsoft Graph API创建了仅1个收件箱消息资源的订阅，POST请求如下：

POST https://graph.microsoft.com/v1.0/subscriptions
Content-Type: application/json

{
  "changeType": "created",
  "notificationUrl": "https://myurl.com/endpoint",
  "resource": "/me/mailfolders('inbox')/messages",
  "expirationDateTime": "{{addMinutes(now; 4225)}}",
  "clientState": "{{uuid}}"
}

异常情况：有时会向我的URL发送2次相同数据，有时1次，有时3次，经对比确认这些通知完全重复。我收到POST后立即返回202响应，重复请求间隔不足1秒，使用Integromat接收通知，不确定是否可通过存储@odata.etag过滤重复。

请问：

1. 该问题原因是什么？
2. 如何实现仅接收1条通知？
3. 是否与邮箱配置有关？
4. 存储@odata.etag是否为标准解决方案？

1. 重复通知的原因 #

• Graph服务端重试机制：即便你立即返回202响应，Graph可能因内部网络延迟、节点同步延迟等问题，未及时接收到确认信号，进而触发快速重试。这类重试的间隔通常很短（不足1秒），属于服务端的冗余保障逻辑。
• 邮件创建的多阶段同步：部分邮件在创建过程中，Exchange后台的规则处理（如自动分类、归档）或邮件属性的异步更新，可能导致created事件被多次触发——尽管最终邮件核心数据一致，但服务端会在不同阶段生成重复通知。

2. 实现单条通知接收的方法 #

• 接收端本地去重：在Integromat中维护一个短期去重缓存，用subscriptionId+clientState+resourceData.id（或@odata.etag）的组合作为唯一标识，收到重复标识的通知直接丢弃。
• 优化响应稳定性：确保你的通知端点能稳定、无延迟地返回202。虽然你提到立即返回，但Integromat的路由或网络波动可能导致Graph未及时收到响应，可尝试在端点直接处理响应逻辑，减少中间环节的影响。

3. 是否与邮箱配置相关？ #

大概率无关。除非你的邮箱设置了重复的服务器端规则（如同一邮件被多次触发移动、标记操作），但这类情况通常会导致邮件属性变化，而非完全重复的created通知。多数重复通知来自Graph服务端的重试或内部同步逻辑，和邮箱配置关联度极低。

4. 存储@odata.etag是否为标准解决方案？ #

是。@odata.etag是Graph资源的版本标识，同一邮件的created事件对应的etag通常一致（除非邮件属性被修改），用它作为去重键是Graph Webhook场景下的标准做法。你可以在Integromat中使用内置数据存储或第三方存储（如表格工具）记录已处理的etag，新通知到来时先检查是否存在，存在则跳过处理。

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