4

When requesting calendars, the ID returned from the calendar sometimes changes. We saw that the name of calendar differs sometimes (agenda or Calendar) - this is also reflected in the changeKey field, but would that mean that the calendar ID also changes?

It does not happen to all of our clients, just a few. What can cause this? What are we missing? We already use the Immutable Id headers, but these don't apply to the calendars according to the docs.

{
        "id": "AAMkADgyMzdkNzAyLTVhZGEtNDg1Yi***AAAAEGAAAqQIxwV34sQLN18DH-lwsGAAAAAYeRAAA=",
        "name": "Agenda",
        "color": "auto",
        "changeKey": "qr2mXiE5k0+ASL9waSq4XAADFAI=",
        "canShare": true,
        "canViewPrivateItems": true,
        "canEdit": true,
        "owner": {
            "name": "***",
            "address": "***@***.com"
        }
    },

Any help is appreciated!

Marc LaFleur
  • 31,987
  • 4
  • 37
  • 63
kendepelchin
  • 2,680
  • 2
  • 21
  • 25
  • 1
    Can you explain how you requested **ImmutableId**? This should be working now for events as well. – Ivan Franjic Sep 28 '19 at 01:12
  • ImmutableId was passed in the headers of the request. My question is about _calendars_, not events; ``` 'Prefer' => 'IdType="ImmutableId"'``` – kendepelchin Sep 30 '19 at 13:46
  • **ImmutableId** should be returned for calendars as well, this is just another 'folder' in the mailbox. Just tried that and getting expected behavior. This is how it should look like: `Prefer:IdType=ImmutableId` – Ivan Franjic Sep 30 '19 at 14:47
  • We already pass this header when requesting calendars but unfortunately it still happens that a calendar gets another ID. Any idea what is happening? – kendepelchin Oct 01 '19 at 08:50
  • This is really strange in case **ImmutableId** is used. How often that happen? Moving folder to another mailbox or to archive could cause this, however, this isn't scenario you are facing. Any chance next time this happens you can paste previous and current (changed) Id? Please note, Id's arent containing any PII data in it. Just some bytes (and guid in case of EntryId). – Ivan Franjic Oct 01 '19 at 11:37
  • Hi @IvanFranjic The id's we're currently seeing are these: original ID: `AAkALgAAAAAAHYQDEapmEc2byACqAC-EWg0AKkCMcFd_LECzdfAx-5cLBgABIY_KcAAA` (Agenda) `AAkALgAAAAAAHYQDEapmEc2byACqAC-EWg0AKkCMcFd_LECzdfAx-5cLBgABLe4oVAAA` (Calendar) New iD: `AAMkADgyMzdkNzAyLTVhZGEtNDg1Yi04ODZhLTczMTRiMGYyMzdkMgBGAAAAAACyNgCTvd0lSK6vQGLKRsMTBwAqQIxwV34sQLN18DH-lwsGAAAAAAEGAAAqQIxwV34sQLN18DH-lwsGAAAAAYeRAAA=` (Agenda) – kendepelchin Oct 01 '19 at 13:33
  • First two (original ID) are **ImmutableId**'s, while new id is **EntryId**. If you've gotten that in your responses, this looks like one request goes out asking for **ImmutableId** and the other goes without that and **EntryId** is returned by default. – Ivan Franjic Oct 01 '19 at 16:14
  • Sorry, I made a booboo, the new (immutable) id is `AAkALgAAAAAAHYQDEapmEc2byACqAC-EWg0AKkCMcFd_LECzdfAx-5cLBgABLe6Y6gAA` (Agenda) While I don't understand these differ from the originals – kendepelchin Oct 01 '19 at 16:49

2 Answers2

4

IIRC, calendars are actually folders under the covers and therefore are not affected by the ImmutableId prefer header. The reason for this is that folder ids are supposed to stay the same within a given mailbox regardless of where they are moved. As such, a calendar only has one id (PR_ENTRYID) and no immutableId (PR_IMMUTABLE_ENTRYID).

That doesn't of course explain what is happening here. I am curious if it is possible that the calendar folder is getting recreated somehow which would explain why the calendar id would be changing. Can you look at the creation time of the folder to see if it is more recent than you expect it to be?

David Sterling - MSFT
  • 580
  • 2
  • 6
  • We changed the uuid used for now, but we can only see that the calendar was first added in april 2019 and that recently (a few weeks ago) the ID that the /me/calendars call returned was different. – kendepelchin Jan 17 '20 at 09:47
1

There is a known issue with calendar folder immutable ids where they do change that is being investigated by our engineering team. Apologies for the inconvenience here.

Jeremy Thake MSFT
  • 2,058
  • 2
  • 13
  • 11