3

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.

Mitch Eagles
  • 96
  • 5
  • Just see that whether (1) these items has any retention policy enabled on them? (2) Do you have any backup/archive solution exists? – Dev Dec 04 '20 at 19:29
  • As you talk about this happens only with events created over a year ago or two years... let me know what you find. – Dev Dec 05 '20 at 07:18
  • @Dev 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. – Mitch Eagles Dec 07 '20 at 14:50
  • you may need to check with your exchange/office 365 administrator to see if they applied any retention policies. – Dev Dec 07 '20 at 17:36
  • 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. – Dev Dec 07 '20 at 18:11
  • @Dev 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. – Mitch Eagles Dec 09 '20 at 15:41
  • 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. – Dev Dec 12 '20 at 18:57

3 Answers3

5

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.

Cory Boyd
  • 189
  • 7
  • They don't exactly seem to acknowledge this in this discussion, unfortunately. https://github.com/microsoftgraph/microsoft-graph-docs/issues/6599 – hbulens Feb 05 '21 at 15:34
1

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.

Stephan
  • 2,356
  • 16
  • 38
  • 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. – hbulens Aug 31 '23 at 16:14
0

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

Merv
  • 83
  • 1
  • 12