Why is Microsoft Graph API telling me events I've just created are being "@removed" when they are still there?

Question

When I am doing a POST to me/calendars/[calendar-id]/events with the following payload. It successfully creates the event, and I receive the new event's id:

{
  "start": {
    "timeZone": "America/Chicago",
    "dateTime": "2022-12-23T15:00:00"
  },
  "end": {
    "timeZone": "America/Chicago",
    "dateTime": "2022-12-23T18:00:00"
  },
  "subject": "Please don't delete me!",
  "body": {
    "contentType": "text",
    "content": "I'm just an event in the future, I wonder if I'll send a '@removed' notice?"
  }
  "isCancelled": false,
  "type": "singleInstance"
}

But shortly after that, my webhook is getting hit with this information for that event, indicating that it was just removed:

{
  "@odata.type": "#microsoft.graph.event"
  "id": [that-event-id]
  "@removed": {
    "reason": "deleted"
  }
}

When I go and look on my Outlook calendar, the event still seems to be present, and if I GET it, isCancelled is false.

This is only happening for events created over a year ago, or two years in the future.

Joubert

Just see that whether (1) these items has any retention policy enabled on them? (2) Do you have any backup/archive solution exists? – Commoner

As you talk about this happens only with events created over a year ago or two years... let me know what you find. – Commoner

@Commoner I'm not aware of any retention policy: what is the best way to find that out? And I'm not sure what your second question is asking, though. We have the data about our events on our end still, but have recorded them as archived because we're being given the @removed notice. – Joubert

you may need to check with your exchange/office 365 administrator to see if they applied any retention policies. – Commoner

In addition, you need to remember the following: (1) In general, Removed instances are represented by their id and an @removed object. (2) In your scenario, you notice "Deleted", it indicates the item is deleted and cannot be restored. That's the reason i asked any retention policy enabled or backup/archive solution exists (3) Also note that the removed object can be returned in the initial delta query response and in tracked (deltaLink) responses. Clients using delta query requests should be designed to handle these objects in the responses. – Commoner

@Commoner there is no admin: this is for an individual account. The problem I'm seeing is that I'm receiving the "deleted" notice moments after I create in via Graph, but the item is not being deleted. When I look ahead on my calendar, the event is still there. – Joubert

If the item exists then as i updated earlier check the retention policies applied on these items or any backup/archive solution exists. In addition, the removed object can be returned in the initial delta query response and in tracked (deltaLink) responses. What you notice at your end? In such scenario, clients using delta query requests should be designed to handle these objects in the responses - thats the way to move forward. – Commoner

Answer 1

Having been plagued by this same issue for about a month ourselves, I think I was finally able to track this down yesterday.

We use the events delta API instead of the webhook API, but apparently the same bug affects both... Someone at Microsoft really needs to fix this, it's insane.

Answer

Changes to events outside of the startDateTime..endDateTime window initially set on the events delta request always show up as a @removed delta.

More details

The events delta API captures the initial startDateTime..endDateTime window, which is then used for all subsequent calls with a $deltatoken. This will also bite you unexpectedly if your delta query uses $select etc. as changes to it will not apply until you create a new delta (by not passing an initial $deltatoken)

This detail is what led us to setting up a bit of a timebomb for ourselves. We had an initial window that was somewhat wide, but suddenly started receiving widespread reports of events showing as cancelled that definitely have not been removed from calendars.

This is a bug

Please, someone from Microsoft acknowledge that this is a real issue. Change made outside the discretely specified time window should NOT affect it, this makes it difficult to build integrations that we trust.

Nellnella

They don't exactly seem to acknowledge this in this discussion, unfortunately. github.com/microsoftgraph/microsoft-graph-docs/issues/6599 – Deadfall

Just my 2 cents, i just discovered the same behaviour, executing my delta request returns entries of id's that are "deleted" while they are NOT. Major bug this, totally unforgivable mistake on Microsofts behalf, i now do a extra call using the event ID for each atremoved.reason assigned. – Octarchy

Answer 2

This only happens to events created over a year ago or two years in the future.

I’m guessing it has something todo with retention policies defined by your organization.

https://learn.microsoft.com/en-us/microsoft-365/compliance/create-retention-policies

With retention policies you can define how long specific items should be kept before being auto removed.

Horwath

True, but that doesn't solve the problem. One day the chickens will come home to roost and will trigger a truckload full of archived events marked as removed. – Deadfall

Answer 3

This can also happen if you end up using the wrong $deltatoken too.

Sectarianism

Answer 4

For other people finding this thread in the future:
I looked into this issue now because I also did not expect the delta endpoint to show events outside the date range as deleted, so our integration also accidentally deleted events that were still active.

I see that the event delta docs now states that this is the expected behaviour:

Within a round of delta function calls bound by the date range of a calendarView, you may find a delta call returning two types of events under @removed with the reason deleted:

• Events that are within the date range and that have been deleted since the previous delta call.
• Events that are outside the date range and that have been added, deleted, or updated since the the previous delta call.

Filter the events under @removed for the date range that your scenario requires.

This explanation seems to have been added the first time on on Jun 21 2021, after this Stackoverflow thread was posted (Dec 3, 2020) according to the Github log. I am guessing that the bug reports linked in the comments above (that are now dead links) eventually was resolved by updating the documentation.

So the integration will have to check each event with @removed to see if they are within the expected date range, or do a lookup in the Graph API to check if the event is actually deleted.

Hine