CODEWITHSUNDEEP
microsoft-graph-apioutlook-calendar
Mitch Eagles
Mitch Eagles

Reputation: 116

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

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.

Upvotes: 4

Views: 1235

Answers (5)

Ravina J
Ravina J

Reputation: 1

I was facing same issue and didn't initially understand how to solve it.

Then, I realized that when I first generated the delta token using the API endpoint /me/calendarView/delta?startDateTime={start_datetime}&endDateTime={end_datetime},

the start_datetime and end_datetime values were out of range. The first time I generated the token, it was within a different range, but when I tried to use that delta token later, I encountered the problem

I was using this API call:

https://graph.microsoft.com/v1.0/me/calendarView/delta?startDateTime=2024-01-01T19:00:00.0000000&endDateTime=2024-01-01T23:59:00.0000000,

but I was creating events in 2025, which caused the issue.

Upvotes: 0

Mythril
Mythril

Reputation: 79

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.

Upvotes: 0

Merv
Merv

Reputation: 81

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

Upvotes: 0

Cory Boyd
Cory Boyd

Reputation: 199

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.

Upvotes: 6

Stephan
Stephan

Reputation: 2580

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.

Upvotes: 1

Related Questions