6

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.

user1157236
  • 76
  • 5
  • Could you add an example of what you're getting back from Graph Explorer? – Marc LaFleur Mar 29 '19 at 16:47
  • I am running into the same problem using retrofit2 implementation of MS Graph. Did you find any solution or workaround? – mattlaabs Dec 12 '19 at 21:02
  • For me, this only happens when the new event is outside of the delta request's start-end time frame. – mattlaabs Dec 13 '19 at 13:56
  • Hi, i am getting same error though event is not truly deleted in calendar. so, any luck? – uma mahesh May 20 '20 at 13:57
  • I never found a solution, I moved on after I implemented my workaround in the Update. Note I never supplied a start-end time frame in the delta request like @mattlaabs, just used the delta link – user1157236 May 21 '20 at 15:06
  • @user1156236 the start + end parameters are mandatory for the original request and will always be applied to future requests using the delta link. – mattlaabs May 22 '20 at 16:39

1 Answers1

3

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
Cory Boyd
  • 189
  • 7