Microsoft Graph subscriptions can't monitor recurring events instances

Question

Microsoft Graph subscriptions can't monitor recurring events instances

Billy | IKANDA 11

Hi,

So I have been building my API to use the Microsoft Graph Subscriptions to read the events of a resource mailbox calendar.

Everything seems to work, the only issue is that when you work with recurring events then all of a sudden you can't check the instances.

It only returns the ID of the master event for that recurring series, while the update wasn't applied to the master but an instance of that recurring series.

Especially when you try to delete an instance of the series no matter how far you delete it in the future it will always send a notification for the entire series, making it kinda impossible to know what instances got deleted...

Any ideas on how to handle recurring events with subscriptions perfectly?

Cause I'm kinda getting clueless on how to process this accordingly.

Thanks in advance!

Kind regards,

Billy

PS: I also added it on: Stackoverflow

1 answer

Your answer

Answer 1

Deepanshu Sharma 500 Microsoft External Staff

Hello @Billy | IKANDA handling recurring events with subscriptions can indeed be tricky, especially when dealing with instances and updates. Let’s break down some strategies to address this challenge:

Master Event vs. Instances:
- You’ve correctly observed that when working with recurring events, the subscription only returns the ID of the master event. This is because recurring events are essentially a series with a common pattern (the master event) and individual occurrences (instances).
  - To handle instances, you’ll need to retrieve the master event and then use recurrence information (such as the recurrence pattern and range) to generate the instances yourself.
Instance Retrieval:
- After receiving the master event ID, you can use the recurrence pattern (e.g., daily, weekly) and the start date to calculate the instances.
  - For example, if the master event is a weekly meeting starting on Monday, you can calculate all the Mondays within the specified range to get the instances.
Tracking Updates:
- When an update occurs (e.g., an instance is modified), you’ll receive a notification for the master event. However, you won’t know which specific instance was updated.
  - To handle this, maintain a mapping between the master event and its instances. When an update notification arrives, compare the updated master event with the instances to identify the affected instance(s).
Deletion Notifications:
- Deleting an instance can indeed be challenging due to the notification behavior you described.
  - One approach is to track deletions separately. When you receive a deletion notification for the entire series, mark the corresponding instance(s) as deleted.
    - You can also use the RecurrenceMasterId property to link the deleted instance back to the master event.
Granularity of Subscriptions:
- Consider the granularity of your subscriptions. You might need separate subscriptions for master events and instances.
  - For instance updates, subscribe to changes on individual instances. For master event updates (e.g., recurrence pattern changes), subscribe to the master event.
Testing and Edge Cases:
- Test thoroughly with various recurrence patterns (daily, weekly, monthly) and edge cases (e.g., exceptions, modified instances).
  - Consider scenarios like exceptions (cancellations or modifications to specific instances) and how they affect the overall series.

Billy | IKANDA 11 Reputation points

2024-01-02T09:55:20.3133333+00:00
Hi @Deepanshu Sharma ,

Happy New Year!

I agree with the idea but it doesn't handle all cases, especially the more complex ones and some points won't work I think.

You said to generate the instances based on recurrence information, but if the end date is not set, generating instances becomes way harder as you have to limit the number of instances and use a separate strategy to create newer instances based on the recurrence information automatically like using cron or hooks to determine if a new instance should be added.

Tracking updates the way you mention won't work either I think. The reason is that if you update an instance of a recurring series the master event won't be updated it will mention that an update happened to the series but not what was changed as the change is not part of the master event. So you are required to retrieve the instances and then compare the information with each other which gets hard to manage depending on the size of the series. This is also a reason why generating the instances isn't a great idea as you still need the id of every instance to be able to compare the information properly.
Also if updates occur for some instances and then the master gets updated knowing which instance will receive the update and which won't, is quite a challenge. Since some instances were updated separately from the series what happens to changes made to the entire series? Will certain information still be updated or will it ignore all changes as it's considered to be decoupled from the recurring series?
For a small series of instances, it won't be much of an issue but with a much larger or never-ending series, this can become troublesome very quickly.

Deleting notifications becomes even trickier... In our system we only delete future events (as in events that happen after tomorrow), once the event starts it won't get removed and instead gets monitored by the system and if deleted it receives a separate deleted status. For regular events this works but for recurring series on the other hand this is harder to monitor. When the entire series gets deleted then I delete every instance in the future but not the instances that are happening or have happened as they will receive a deleted status instead. The master event won't be deleted either since there are still instances that exist but I would need to add a status so it will no longer be monitored in case it had an infinite duration.
But what if a future instance gets deleted from the series? If I delete it from my side how will it know that the event got deleted on purpose and isn't an event that failed to get generated with the recurrence?

Creating subscriptions for events works but you can only subscribe to all events of a mailbox, not individual ones as stated in the documentation: Microsoft Graph. So the only way would be by using regular requests instead and combining them with cron to ensure the changes get applied.

I have been thinking about this for the past few weeks but I am unable to get a good solution for this as I always keep ending up with more issues than before.

Any ideas?

Thanks in advance!

Kind regards,

Billy
Will Overton 0 Reputation points

2024-09-12T13:06:10.49+00:00

@Billy | IKANDA Did you ever come up with a good solution?
James 1 Reputation point

2024-11-27T15:32:20.8933333+00:00

I am are running into the same issues with trying to figure out how to best detect changes within a specific instance of a series. Seems like a huge oversight to not consider this on Microsoft's part?

Share via

Microsoft Graph subscriptions can't monitor recurring events instances

1 answer

Your answer