Calendar Id randomly changed

Question

Whats the reason that make a calendar change it's id when using microsoft graph ???

This happened today for one of our clients who's been using his main Calendar for over 2 years, and suddenly today, the id is changed and we are unable to add any event since we have the 'old' id

Endpoint being called:

/me/calendars/AAMkAGFmMzAxNmRkLTg4YTEtNDNhZS1iYjExLWE1OThlYThlNTRmOQBGAAAAAACxNL6zUoo_Qr9AY8vFoIfmBwBstbpyrelbSJu1keAu6bMkAAAAAAEGAABstbpyrelbSJu1keAu6bMkAAAAAFB8AAA=/events

Error returned:

{
  "error": {
    "code": "ErrorItemNotFound",
    "message": "The specified object was not found in the store."
  }
}

Headers:

{
  "Cache-Control": [
    "private"
  ],
  "Content-Type": [
    "application/json; odata.metadata=minimal; odata.streaming=true; IEEE754Compatible=false; charset=utf-8"
  ],
  "request-id": [
    "63353567-4ebd-4b25-903b-d66717797882"
  ],
  "client-request-id": [
    "63353567-4ebd-4b25-903b-d66717797882"
  ],
  "x-ms-ags-diagnostic": [
    "{\"ServerInfo\":{\"DataCenter\":\"North Europe\",\"Slice\":\"SliceC\",\"Ring\":\"4\",\"ScaleUnit\":\"001\",\"RoleInstance\":\"AGSFE_IN_6\"}}"
  ],
  "Strict-Transport-Security": [
    "max-age=31536000"
  ],
  "Date": [
    "Thu, 04 Feb 2021 10:40:39 GMT"
  ],
  "Content-Length": [
    "99"
  ]
}

New calendar id: AAMkAGFmMzAxNmRkLTg4YTEtNDNhZS1iYjExLWE1OThlYThlNTRmOQBGAAAAAACxNL6zUoo_Qr9AY8vFoIfmBwBstbpyrelbSJu1keAu6bMkAAAAAAEGAABstbpyrelbSJu1keAu6bMkAAF8qLRIAAA=

Edit: (Happened for another client) It happened again today with another client (another tenant-id), here are details:

Old calendar id:

AAMkAGI2Y2NkYzVmLTc3ZjUtNDQyNi1iNjIzLTljNjkyMDk5YjEyYwBGAAAAAADQqVqZh-ZpQJl-EcoJBivzBwCE3CCn1SYkSLnEBiNMaH3ZAAAAAAEGAACE3CCn1SYkSLnEBiNMaH3ZAAAAAB08AAA=

{
   "Cache-Control":[
      "private"
   ],
   "Content-Type":[
      "application\/json; odata.metadata=minimal; odata.streaming=true; IEEE754Compatible=false; charset=utf-8"
   ],
   "request-id":[
      "2f9ddb93-3594-4d86-97f9-d7dbe960a2bb"
   ],
   "client-request-id":[
      "2f9ddb93-3594-4d86-97f9-d7dbe960a2bb"
   ],
   "x-ms-ags-diagnostic":[
      "{\"ServerInfo\":{\"DataCenter\":\"North Europe\",\"Slice\":\"SliceC\",\"Ring\":\"4\",\"ScaleUnit\":\"001\",\"RoleInstance\":\"AGSFE_IN_71\"}}"
   ],
   "Strict-Transport-Security":[
      "max-age=31536000"
   ],
   "Date":[
      "Mon, 08 Feb 2021 11:08:53 GMT"
   ],
   "Content-Length":[
      "99"
   ]
}

New calendar id:

AAMkAGI2Y2NkYzVmLTc3ZjUtNDQyNi1iNjIzLTljNjkyMDk5YjEyYwBGAAAAAADQqVqZh-ZpQJl-EcoJBivzBwCE3CCn1SYkSLnEBiNMaH3ZAAAAAAEGAACE3CCn1SYkSLnEBiNMaH3ZAAGPkTa6AAA=

Answer 1

Here's a piece of the puzzle... Those look Base64 encoded. If you Base 64 decode the old and the new IDs, you'll find the same GUIDs are embedded inside it.

(Use https://www.base64decode.org/)

Old decoded: $af3016dd-88a1-43ae-bb11-a598ea8e54f9F4R?B@cŠlr[H.$lr[H.$P|
New decoded: $af3016dd-88a1-43ae-bb11-a598ea8e54f9F4R?B@cŠlr[H.$lr[H.$|H
(guid: af3016dd-88a1-43ae-bb11-a598ea8e54f9)
- 
2nd example provided 
Old decoded: $b6ccdc5f-77f5-4426-b623-9c692099b12cFЩZi@~    + &$H#Lh} &$H#Lh}<
New decoded: $b6ccdc5f-77f5-4426-b623-9c692099b12cFЩZi@~    + &$H#Lh} &$H#Lh}6
(guid: b6ccdc5f-77f5-4426-b623-9c692099b12c)

If it is not possible to use the embedded GUID via a query in the graph request, then maybe call https://graph.microsoft.com/v1.0/me/calendars, decode all the calendars, find the ID with the matching embedded GUID, and use that one? It would add an extra call, but you might be able to do it in exception handling, as no state is required. This may help with your existing application.

I can't guarantee this would work as I don't have data over time to test this theory with... but you do :)

To avoid this issue with ID changes going forward, look into storing immutable IDs wherever possible. You cannot store them for containers (calendars, mailboxes, etc), but perhaps moving forward you can store them for the events that your application creates, so you can work backwards from there.

Container types (mailFolder, calendar, etc.) do not support immutable ID, but their regular IDs were already constant.

This line from their documentation is notable, as your experience does not match what their documentation states. This opens scope for you to complain to MS, or at least meaningfully blame their wrong documentation.

Also, I'd be asking IT in both orgs if they changed anything related to AAD Sync or Exchange? I have got a wild theory it's related to that. There was an email that went out recently asking people to update AAD sync, and this pattern just feels familiar to some sort of auth provider change.

---

Update: as to solving this problem directly; A potential way could be to have an exception handling piece of logic that only runs when the URL 404s. It would behave as follows:

1. Using regex, Get the base64 decodable segment of the URL and decode it.
2. Using regex, Find all possible matches for a GUID. (regex?)
3. Use the Graph API to find the calendar identified by any found GUID.
4. Use new URL, and see if that works.
5. If it does, update your record to the new URL.

Answer 2

The problem is not that the calendar id changed. It seems like you just have to deal with it, and you have a good way to find the new Id, as stated in the above comment.

The problem is that you use the ID Microsoft is generating, in your app, and now they don’t match. It’s perfectly possible to add extra data to an event (or a user/group). See this page for more info. That way you can just add your external ID to the event while creating and then you can always find back the event.