5

我正在使用@microsoft/microsoft-graph-client带有基本 url 的 npm 包同步日历事件/me/calendarview/delta。直到几天前它一直运行良好。出于某种原因，每当我在 outlook.office.com 中创建新的日历事件并且我的应用程序同步时，新创建的日历事件都会@removed: {reason: "deleted"}设置该字段。

但是，当我使用 Microsoft Graph Explorer 查找相同的日历事件时，相同的事件没有@removed设置字段。是否有任何理由让新创建的日历事件看起来像是在同步期间被删除？我正在使用@microsoft/microsoft-graph-client v1.3.0

重建步骤：

  1. 通过 POST 使用节点图客户端创建事件/me/calendar/events
  2. /me/calendarview/delta使用适当的 deltaLink 和访问令牌获取日历事件的增量。
  3. @odata.type我收到 1 个具有 3 个字段、id和的日历事件@removed。id 字段与步骤 1 中创建的事件的 id 匹配。

如果您需要更多信息，请告诉我。这影响了我们的一些用户。

更新：我尝试了解决此问题的方法，方法是调用我在增量同步上收到/me/events/<id>的每个@removed日历条目，以验证该事件是否真的被删除。但是，当我通过 microsoft-graph-client 调用该 API 时，它返回 null。如果我通过MSFT Graph Explorer进行相同的 GET 调用，则返回该事件。

4

1 回答 1

2

我在这里留下了另一个问题的答案：https ://stackoverflow.com/a/65348721/6806302

简而言之，我昨天受到@mattlaabs 对上述问题的评论的启发而开始预感，事件增量的 startDateTime..endDateTime 范围是罪魁祸首。

在实践中，这正是问题所在。答案分为两部分：

  1. 对不在窗口中的事件的更改始终在增量流中显示为@removed。
  2. 事件增量参数在“闭包”中捕获，这意味着后续请求（带有 a $deltatoken）忽略startDateTime..endDateTime查询参数。

了解以上两点，似乎答案是：

  1. 创建足够宽的初始startDateTime..endDateTime窗口以满足您的应用程序的需求
  2. 以某个定义的时间间隔开始新的事件增量流（不提供 a $deltatoken），而不是无限期地重复使用同一个
于 2020-12-17T21:47:40.227 回答