I would like to add to this issue:
A different error code will not be enough.
We have experienced this problem when the API tried to deliver too much data in a single response. A lot of data that can be delivered using paging is no problem, but the two main scenarios we experienced where the API does not use paging and will run into 503s reliably are:
- long event series with many exceptions
- events with veeery long participant lists
For the second case there is no possibility at all to reduce the window.
But also for the first case there is no feasible way to handle this. Even if we had a good estimate of how many events fit into a single response, we lack information about the recurrence data of the faulty series to adjust the window accordingly.
Our only "solution" to this is currently to have users manually check for potentially blocking events and delete/change them.
This is by far our biggest problem with the API. User are very annoyed. Unfortunately we have to keep telling them that this is a Microsoft issue and we can't do much about it.
It is easily reproducable too:
- Create a series with 250 repetitions
- patch all repetitions into series exceptions (i.e. change something)
- run a delta query for a window that will contain all 250 repetitions
- see 503s
Unfortunately I can only upvote once.
Regards
Demian