microsoft-graph-api - 同步新日历事件始终具有 @removed 字段

Question

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

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

重建步骤:

通过 POST 到 /me/calendar/events 使用节点图客户端创建事件

使用 /me/calendarview/delta 获取日历事件的增量使用适当的 deltaLink 和访问 token 。

我收到 1 个包含 3 个字段的日历事件，@odata.type , id和 @removed . id 字段与步骤 1 中创建的事件的 id 匹配。

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

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

Answer 1

我在这里留下了另一个问题的答案:https://stackoverflow.com/a/65348721/6806302
简而言之，我昨天因受 @mattlaabs's comment on the question above 启发而产生的预感出发了。 ，事件增量的 startDateTime..endDateTime 范围是罪魁祸首。
在实践中，这正是问题所在。答案分为两部分:

对不在窗口中的事件的更改始终在增量流中显示为@removed。

事件增量参数在“闭包”中捕获，这意味着后续请求(带有 $deltatoken )忽略 startDateTime..endDateTime查询参数。

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

创建足够宽的初始 startDateTime..endDateTime满足您应用程序需求的窗口

以某个定义的时间间隔开始新的事件增量流(通过不提供 $deltatoken )，而不是无限期地重复使用相同的