使用Microsoft Graph API订阅Teams消息时含URL消息触发多次通知

可能的原因分析 #

• Teams对含URL的消息会进行链接预览处理：发送带URL的消息时，Teams后台会自动抓取链接内容生成预览卡片，这个过程会修改消息实体（比如新增预览相关属性），导致Graph检测到多次变更，进而触发多轮通知。
• 消息的状态流转触发多轮通知：消息从“待发送”到“已发送”再到“生成预览完成”，每个状态节点都可能被判定为一次变更，尤其是链接预览的异步处理会延迟触发额外通知。

可行的解决办法 #

1. 本地去重处理：
   • 提取通知中的resourceData.id（消息唯一ID）和subscriptionId，本地维护一个短时间缓存（比如1分钟），如果相同消息ID在缓存期内重复收到通知，直接忽略后续请求。
   • 注意要区分不同订阅的消息，避免跨订阅的正常通知被误过滤。
2. 精准设置订阅的变更类型：
   • 检查订阅请求的changeType参数，确保只订阅created事件，而非updated。因为链接预览属于消息更新操作，若订阅了updated会额外触发通知。
   • 示例订阅核心参数：

     {
       "changeType": "created",
       "resource": "/teams/{team-id}/channels/{channel-id}/messages",
       "notificationUrl": "你的Webhook地址"
     }
     

3. 过滤更新类通知：
   • 在Webhook接收逻辑中，先判断通知的changeType，如果是updated，后续调用Graph获取消息详情，若发现是链接预览导致的属性变更，直接跳过处理。
4. 延迟消息查询时机：
   • 收到通知后不要立即调用Graph拉取消息，等待2-3秒再执行查询，避免获取到未完成预览的中间状态消息，同时减少重复通知带来的无效API调用。

额外注意点 #

• 确保返回202响应的逻辑完全无阻塞：即使后续处理放在单独线程，也要确认Webhook路由没有因日志打印、异常捕获等操作延迟响应，响应延迟可能导致Graph重试发送通知。
• 检查租户消息安全配置：部分租户开启了链接安全扫描，这个过程也会修改消息状态触发额外通知，可联系租户管理员确认相关设置。

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