CODEWITHSUNDEEP
microsoft-graph-apimicrosoft-graph-sdksmicrosoft-graph-calendar
user1157236
user1157236

Reputation: 76

Synchronizing new calendar events always have the @removed field

I'm syncing calendar events using the @microsoft/microsoft-graph-client npm package with the base url /me/calendarview/delta. It's been working fine until a few days ago. For some reason whenever I create a new calendar event in outlook.office.com and my app syncs, the newly created calendar event has the @removed: {reason: "deleted"} field set.

However when I lookup that same calendar event using the Microsoft Graph Explorer that same event does NOT have the @removed field set. Is there any reason a newly created calendar event would look like it's being deleted during a sync? I'm using @microsoft/microsoft-graph-client v1.3.0

Steps to recreate:

  1. Create an event using the node graph client by POSTing to /me/calendar/events
  2. Grab a delta of calendar events using /me/calendarview/delta with appropriate deltaLink and access token.
  3. I receive 1 calendar event that has 3 fields, @odata.type, id and @removed. The id field matches the id of the created event in step 1.

If you need more information, let me know. This is affecting some of our users.

Update: I tried a workaround for this issue by calling /me/events/<id> for each @removed calendar entry I receive on a delta sync to verify if the event was truly deleted. However when I call that API via the microsoft-graph-client it returns null. If I make the same GET call via MSFT Graph Explorer then the event is returned.

Upvotes: 6

Views: 779

Answers (1)

Cory Boyd
Cory Boyd

Reputation: 199

I left an answer on another question here: https://stackoverflow.com/a/65348721/6806302

In short, I went off yesterday on a hunch inspired by @mattlaabs's comment on the question above, that the startDateTime..endDateTime range of the events delta was to blame.

And in practice, that is exactly the problem. The answer is two part:

  1. Changes to events not in the window always show up in the delta stream as @removed.
  2. The events delta parameters are captured in a "closure", meaning subsequent requests (with a $deltatoken) ignore the startDateTime..endDateTime query parameter.

Understanding both of the above, it seems that the answer is to:

  1. Create wide enough initial startDateTime..endDateTime windows to suite your application's needs
  2. Start new events delta streams (by not providing a $deltatoken) at some defined interval instead of reusing the same one indefinitely

Upvotes: 3

Related Questions