While syncing messages via the mailFolder delta endpoint, specific mailFolders will provide #odata.deltaLinks that when requested return 503 errors.
This affects 4 of roughly 6500 mailFolders that we are currently syncing. Each of these 4 is in a different Office 365 tenant, and includes both default (e.g. "Sent Items") and custom folders.
#odata.nextLink works correctly. The mailFolder receiving new messages also doesn't fix the issue:
If the syncing progress is restarted, that is, throwing away the existing #odata.deltaLink, following the #odata.nextLink chain will correctly return all messages (including ones created after the deltaLink was provided). However, the newly provided #odata.deltaLink, while different, will also return the error.
This issue affects both the 1.0 and beta versions of this endpoint.
All other mailFolders for the affected users work correctly.
This issue has existed from the very first time we've attempted to sync affected mailFolders. The first time that we saw it was 2019-08-03 08:38 PM UTC, though the issue has likely existed longer than this.
The response does not include a Retry-After header.
All of our other 6500 mailFolders have correctly functioning message deltas, and we're able to correctly sync them with our code.
Can be reproduced via Curl to an affected message delta URL.
curl -H "Authorization: Bearer $access_token" "$delta_url"
A sample of one of the specific error codes returned, with a real request id:
Request to:
https://graph.microsoft.com/v1.0/me/mailFolders/<mailFolderId>/messages/delta?$skiptoken=<skipToken>
{
"error": {
"code": "UnknownError",
"message": "Error while processing response.",
"innerError": {
"request-id": "a4441195-f469-47c8-bea3-cdeedef2e396",
"date": "2019-08-08T21:24:20"
}
}
}
This other potentially relevant header was on the response:
x-ms-ags-diagnostic: {"ServerInfo":{"DataCenter":"West US","Slice":"SliceC","Ring":"5","ScaleUnit":"003","RoleInstance":"AGSFE_IN_7","ADSiteName":"WUS"}}
Related
We previously posted this issue on GitHub regarding concerns over limits for subscribing to calendar changes for rooms: https://github.com/microsoftgraph/microsoft-graph-docs/issues/5709
The answer we got was that "No, there aren't any [limits] that you should be concerned about."
However, we have started to see this response when trying to register a webhook to subscribe to changes to a calendar of a room:
Invalid response - 429:
{
"error": {
"code": "ExtensionError",
"message": "Operation: Create; Exception: [Status Code: 429; Reason: Resource 'MaxTotalRequests' has reached limit of '5000'. Please retry after '9/23/2019 2:20:44 PM']",
"innerError": {
"request-id": "43b79bf3-ddee-4bc3-b436-9caa7bff81ac",
"date": "2019-09-23T14:20:42"
}
}
}
We aren't making any large amount of subscriptions, and we only get this response when we are trying to register subscriptions to calendars of users or resources (i.e. not when making other requests to msgraph which are not related to subscriptions). There was a total of 210 subscription related requests made (either subscribing, extending a subscription, or deleting a subscritpion) between 10min before this error and 10min after. Any guidance?
This isn't really a subscription limit so much as an Exchange Online limit. The message is telling you that you've hit the throttling. Exchange's throttling is based on n requests per 10m window. Your code needs to recognize the HTTP 429 and handle it accordingly.
You find complete details in the Microsoft Graph throttling guidance.
I am connecting to Notebooks stored on SharePoint and getting "UnknownError" using the Graph API when trying to retrieve Pages.
I have no problem querying notebooks, sections or sectiongroups - that's all working, so no authentication problems or anything
Request:
https://graph.microsoft.com/v1.0/sites/{app id}/onenote/pages
Error below:
{
"error": {
"code": "UnknownError",
"message": "",
"innerError": {
"request-id": "65721acc-f0d9-40d6-bf80-aac1507a6c2f",
"date": "2018-01-02T17:34:21"
}
}
}
Graph explorer returns this after about 30 seconds, so I'm guessing it's timing out. There are about 10 notebooks in the site I'm connecting to, which each have several hundred pages
I do only need to return 1 page at a time in almost every case. I have tried adding a $filter= at the end, but get the same problem
I would strongly recommend to get pages for each section rather than getting all the pages that the user has access to.
Please refer to the bottom 2 recommendations in this article: https://blogs.msdn.microsoft.com/onenotedev/2017/07/21/a-few-performance-tips-for-using-the-onenote-api/
I just tried this request according to the documentation here
The message ID in this URL is the id of an email that I just retrieved from GET /me/messages
POST https://graph.microsoft.com/v1.0/me/messages/{id}/createReplyAll
Content-Type: application/json
Authorization: Bearer eyJ0eXSiOBJiV1QiLCJub25jZSI6Ik{....}
This is what comes back:
"error": {
"code": "InternalServerError",
"message": "Object reference not set to an instance of an object.",
"innerError": {
"request-id": "a4c28622-0914-44da-8e67-6eb7ee59dc84",
"date": "2017-10-09T19:07:00"
}
}
I'm left to guess whether this is
A bad request (the 500 error doesn't seem to imply that)
This type of email is special and cannot be accessed or replied to for some reason (?) or
I found a bug and this is my bug report.
The same happens for /createReply endpoint as well
I just reproduced this as well. Remove the Content-Type header to fix this. It seems the server is running into a bad error case when you say there's JSON in the body, but the body is empty :). This is definitely a bug in that we should never return a 500.
And I see that the Graph docs say that the header is required, even though there's no body. That seems like a doc bug to me.
I'll report up to the right folks.
Thanks; that header had been left in there as an oversight. FYI I removed the header in the 3 topics for createForward, createReply, and createReplyAll in v1.0 of Microsoft Graph. The updates will be live within 24 hours.
For our internal application we synchronize our user's calendars (in our Office 365 tenant) with a local "cache" in our database. We're using the new Delta Queries in Microsoft Graph to do track these changes.
Most of the calendars synchronize correctly, but for some reason there is one single calendar where we consistently hit a 504 Gateway Timeout error when attempting to request the events using the nextLink received from the first request.
First request:
GET https://graph.microsoft.com/v1.0/users/<userId>/calendars/<calendarId>/calendarView/delta?startDateTime=2017-06-10t00%3A00%3A00Z&endDateTime=2018-06-10t00%3A00%3A00Z
First response:
{
"#odata.context": "https://graph.microsoft.com/v1.0/$metadata#Collection(event)",
"#odata.nextLink": "https://graph.microsoft.com/v1.0/users/<userId>/calendars/<calendarId>/calendarView/delta?$skiptoken=R0usmcdvmMuZCBYV0hguCGmIJqcU0n_6jVFWUlNKbXkBKYVlxLSMsISZI5sLLLJyLJF8hZIj0PURpAeP_XxydW_qbMUoFMTXjOpLa8Ta6rxMRA7Wv6IHYfjyLPcDzCbM_hKvTgq8BZaBeJv-a61mebF6X2wT4HqCAGL5lL4nLZabHk1nD9GbWJ0a4Qq0M41_GPYxEi5YNe9u1673SQ1Djw.F85xXB6GjtO7myCQCOgFvzp1G7mQB0BvuHQJyn0CICQ",
"value": [
<list of events>
]
}
Second request:
GET https://graph.microsoft.com/v1.0/users/<userId>/calendars/<calendarId>/calendarView/delta?$skiptoken=R0usmcdvmMuZCBYV0hguCGmIJqcU0n_6jVFWUlNKbXkBKYVlxLSMsISZI5sLLLJyLJF8hZIj0PURpAeP_XxydW_qbMUoFMTXjOpLa8Ta6rxMRA7Wv6IHYfjyLPcDzCbM_hKvTgq8BZaBeJv-a61mebF6X2wT4HqCAGL5lL4nLZabHk1nD9GbWJ0a4Qq0M41_GPYxEi5YNe9u1673SQ1Djw.F85xXB6GjtO7myCQCOgFvzp1G7mQB0BvuHQJyn0CICQ
Second response:
504 Gateway Timeout
{
"error": {
"code": "UnknownError",
"message": "",
"innerError": {
"request-id": "0784cffb-cba7-424b-be1d-74b2bfef5da1",
"date": "2017-07-10T09:11:33"
}
}
}
I've tried executing the script a few times over the last week, but the request consistently fails when using requesting the second page. Other calendars synchronize with no issues, so I don't really know how to debug these kind of issues. Is there anything we can do to resolve this issue?
I'm working with the team that owns Calendar sync to check where the latency in the stack is causing this time out. I'll post as soon as they have root caused this. I may need more info on what is special about this one Calendar encountering this issue.
Thanks,
Sri
I am attempting to create a interface between our web application and the GraphApi.
I am currently struggling to handle error correctly as the documentation for graph API seems to be at best incomplete. Is there a reference to full list of errors one should expect.
An example of the issue is where I make a request after my access token has expired. The error code is not on the list (graph.microsoft.io docs/overview/errors page) and in a different format (capitalization). It also seems to vary drastically from the azure error codes such as "Request_BadRequest". This was found in an MSDN article titled "Error codes and error handling | Graph API concepts".
The document states "You may use the information returned here instead of, or in addition to the HTTP status code returned.". However, this is really hard if they are changing despite being out of beta.
example of an error response body:
{ "error": {
"code": "InvalidAuthenticationToken",
"message": "Access token has expired.",
"innerError": {
"request-id": "267438d2-4cc5-4621-9307-2af26d2f5b49",
"date": "2016-02-16T13:30:24"
}
}
}