如何解决Microsoft Graph重复发送事件变更通知问题？

针对你遇到的Graph重复发送事件变更通知的问题，结合实践经验给出以下排查和解决建议：

1. 确保202响应的及时性 #

• 必须在接收通知的第一阶段就返回202 Accepted，绝对不能在处理业务逻辑（如数据库写入、第三方API调用）之后才返回。Graph会在规定时间内等待响应，超时未收到202就会触发重试。
• 把业务逻辑放到返回202之后的异步流程中，示例代码如下：

public static async Task<IActionResult> Run(HttpRequest req, ILogger log)
{
    // 立即返回202，告知Graph已收到通知
    var acceptResponse = new StatusCodeResult(202);
    
    // 异步处理通知内容，不阻塞响应返回
    _ = ProcessNotificationContentAsync(req, log);
    
    return acceptResponse;
}

private static async Task ProcessNotificationContentAsync(HttpRequest req, ILogger log)
{
    // 读取并解析通知体
    var notificationContent = await new StreamReader(req.Body).ReadToEndAsync();
    // 执行幂等校验、业务逻辑等操作
}

2. 实现通知的幂等处理 #

• 每个Graph通知都带有唯一的notificationId字段，用这个字段作为唯一标识，在处理前先检查是否已经处理过该通知。
• 可以借助Azure Storage Table、Redis等轻量存储记录已处理的notificationId，收到重复通知时直接跳过处理。

3. 检查订阅配置是否重复或异常 #

• 调用Graph API GET /subscriptions 查询已创建的订阅列表，确认没有重复创建同一资源路径的订阅。重复订阅会导致同一变更触发多次通知。
• 确认订阅的expirationDateTime设置合理，避免因订阅过期频繁重建，重建过程中可能出现临时的重复通知。

4. 排查Azure Function的响应稳定性 #

• 查看Azure Function的执行日志，确认每次通知都成功返回了202，没有出现响应超时、5xx错误等情况。任何非202的响应都会触发Graph的重试机制。
• 尽量将Azure Function部署在与Graph服务接近的区域，减少网络延迟导致的响应超时。

5. 确认Graph重试机制的影响 #

• Graph的重试策略为指数退避，即使返回了202，极端网络场景下仍可能出现少量重试。此时通过notificationId的幂等校验即可过滤重复通知。

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