Microsoft Graph更改通知是否保证对CREATED事件发送UPDATED通知？

你观察到的「每一个新生成的日历CREATED事件，API必然至少触发一次后续UPDATED通知」的行为，属于Microsoft Graph API变更订阅能力对日历资源的保证性行为，不存在偶发不触发的分支场景。

• 日历事件的创建操作本身不是单步原子流程，整个流程必然会产生两次独立的变更通知：
  1. 第一步是事件对象的初始化落库：系统为待创建事件分配全局唯一对象ID、写入基础草稿元数据，这一步会触发首次created类型的变更通知
  2. 第二步是事件状态的最终补全：系统会完成权限校验、重复事件序列关联、iCalUID等全局关联字段的写入，有参会人的场景还会同步分发邀约，这一步会直接修改刚初始化完成的事件对象本身，因此必然触发一次updated类型的变更通知
• 这一流程是Graph日历服务的固定处理链路，不存在通过内部优化跳过后续状态补全步骤的可能性，也就不会出现“只发创建通知不发后续更新通知”的情况。

你计划采用的「仅订阅UPDATED和DELETED通知，通过本地是否存在对应事件副本的逻辑，将UPDATED通知分流处理为潜在的新建/更新场景」的设计是完全可靠的，不会遗漏任何CREATED事件，原因如下：

• 创建流程触发的那次UPDATED通知，会携带完整的事件对象信息、和其他常规UPDATED通知无差异，不存在内容裁剪、权限缺失的问题，你可以正常通过通知中附带的资源端点拉取完整事件详情写入本地副本
• 这种设计反而能解决订阅机制自带的乱序问题：在网络传输异常的场景下，紧跟创建操作的UPDATED通知可能先于CREATED通知到达你的服务端，如果你单独依赖CREATED通知判断新建场景，反而会因为收到更新通知时本地无对应记录，触发无意义的错误重试。

• 不需要依赖通知的changeType字段判断事件的生命周期：创建流程触发的后续通知，其changeType固定为updated，不会被特殊标记，你完全可以通过本地存储的事件ID/iCalUID判断分流逻辑，和通知类型无关
• 订阅生命周期内新创建的事件，必然会被上述的两次通知流程覆盖，不存在仅发送CREATED通知、跳过后续UPDATED通知的特殊场景；对于订阅创建之前就已经存在的存量事件，不会触发任何通知，需要你在服务初始化阶段通过全量拉取完成基础同步，这和本次讨论的新建通知逻辑无关。

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