使用Microsoft Graph订阅Presence状态时重复接收不必要更新事件的问题

我之前也碰到过类似的Presence订阅重复推送的情况，即使用户的activity和availability完全没变化，也会每隔1-2分钟收到一模一样的通知。结合经验和官方文档的细节，咱们来分析原因和解决办法：

可能的原因 #

• 服务心跳/确认机制：Microsoft Graph的Webhook订阅有时候会发送重复通知，用来确认你的端点是活跃的。不过1-2分钟的频率确实偏高，可能是特定场景下的异常触发。
• 内部属性变更触发更新：Presence对象除了可见的activity和availability，还有一些后台维护的属性（比如lastActiveTime、expiration相关字段），这些字段的微小变更可能会触发updated类型的通知，而前端感知不到状态变化。
• 订阅过滤条件的潜在问题：如果你的$filter参数格式有细微问题（比如用户ID列表的引号、逗号分隔是否正确），可能导致订阅的资源范围识别异常，引发重复推送。

可行的解决方案 #

1. 在Webhook端点实现去重逻辑 #

这是最直接的临时解决办法。你可以在收到通知后，提取resourceData里的activity和availability字段，和最近缓存的该用户状态做对比：

• 如果字段完全一致，直接忽略这条通知；
• 如果有变更，再处理业务逻辑。

缓存可以用内存存储或者轻量数据库，注意设置合理的过期时间（比如5分钟），避免内存占用过高。

2. 检查订阅请求的参数正确性 #

看你提供的订阅请求，重点确认resource里的$filter生成的字符串格式是否符合要求。正确的格式应该是：

/communications/presences?$filter=id in ('user-id-1','user-id-2','user-id-3')

确保@{body('Преобразование_в_строку_Массива_1')}生成的是用单引号包裹、逗号分隔的用户ID列表，没有语法错误。

3. 联系Microsoft 365支持排查 #

如果去重后仍然觉得通知频率异常，或者怀疑是租户特定的服务问题，可以通过Microsoft 365 Admin Center提交支持工单，提供你的订阅ID、租户ID和重复通知的示例，让官方团队排查后台的推送逻辑。

你的订阅请求参考 #

你提供的创建订阅请求示例：

{
  "inputs": {
    "method": "POST",
    "uri": "https://graph.microsoft.com/v1.0/subscriptions",
    "headers": {
      "Authorization": "Bearer @{body('Анализ_JSON')?['access_token']}"
    },
    "body": {
      "changeType": "updated",
      "notificationUrl": "@{variables('Адрес веб-хука')}",
      "resource": "/communications/presences?$filter=id in (@{body('Преобразование_в_строку_Массива_1')})",
      "expirationDateTime": "@{body('Получение_будущего_времени')}",
      "clientState": "secretClientValue",
      "latestSupportedTlsVersion": "v1_2"
    }
  }
}

内容的提问来源于stack exchange，提问作者Евгений Зотов