Sometimes Microsoft outlook or graph API return HTTP 503 ResourceUnhealthy error response for specific mailboxes.
The description mentions: ResourceUnhealthy SystemMemoryProtectionUtilizationMonitor is unhealthy
What does it means and what may cause this specific "ResourceUnhealthy" case ?
Related
When hitting a throttle limit on SharePoint, MS Graph returns an HTTP 304 with a redirect to /_layouts/15/throttle.html instead of a 429 error on SharePoint endpoints (sites, lists, my documents from OneDrive). Is this intended and should we check for this in our code, or is this a bug? I couldn't find any known issues or documentation on this.
We only started seeing this due to the the SPO throttle issues (see; https://github.com/SharePoint/sp-dev-docs/issues/4336). Hitting a general graph throttle still returns the expected 429.
We have a registered AAD application marked as multi-tenant. We are using this App ID to generate a Token for Microsoft Graph.
The first user is a Global Admin in the Tenant where the app is registered.
The second user is part of another Tenant.
When the second user tried to use Microsoft Graph to get information from OneDrive, we sometimes get an HTTP 429 activityLimitReached error.
We read the guide about throttling and it says to repeat the request after the Retry-After value from the response header. But in our case there is no Retry-After field in the response.
We received this error by executing one request per day. Also, after receiving the 429, we can retry and get a successful result (after several attempts). This error appears only in the OneDrive, the other services are OK.
What can we do to avoid 429 error? How can we check the current limit or increase it?
Example of request
GET https://graph.microsoft.com/v1.0/users/:userId/drives
Example of response
HTTP/1.1 429
Cache-Control: private
Transfer-Encoding: chunked
Content-Type: application/json
request-id: 377d2cdf-7be3-4286-819a-46060330365f
client-request-id: 377d2cdf-7be3-4286-819a-46060330365f
x-ms-ags-diagnostic: {"ServerInfo":{"DataCenter":"West Europe","Slice":"SliceA","Ring":"4","ScaleUnit":"000","Host":"AGSFE_IN_13","ADSiteName":"AMS"}}
Duration: 170.5668
Strict-Transport-Security: max-age=31536000
Date: Wed, 23 May 2018 11:39:08 GMT
{
"error": {
"code": "activityLimitReached",
"message": "The request has been throttled",
"innerError": {
"request-id": "377d2cdf-7be3-4286-819a-46060330365f",
"date": "2018-05-23T11:39:09"
}
}
}
What can we do to avoid 429 error? How can we check the current limit or increase it?
To avoid the 429 error, we must control our request, don't do too many request within limited time. The limit issue is known issue we canot increase it now.
Setting and publishing exact throttling limits sounds very straightforward, but in fact, it's not the best way to go. We continually monitor resource usage on SharePoint Online. Depending on usage, we fine-tune thresholds so users can consume the maximum number of resources without degrading the reliability and performance of SharePoint Online.
Above reference is from MS documentation about throttling and OneDrive for Business/SharePoint: https://learn.microsoft.com/en-us/sharepoint/dev/general-development/how-to-avoid-getting-throttled-or-blocked-in-sharepoint-online
I would suggest going to UserVoice for Graph and suggest an improvement (or upvote an existing one). The feedback helps Product Group prioritize future work based on the interest in those suggested improvements. But based on the above official docs, the best solution is still to contorl our request but not the feature request.
I do not have much experience with the onedrive-api but I have certainly experienced throttling when using the onenote-api. This post on how onenote throttles may be more useful than the generic microsoft graph link in your question. In particular, long calls against the api will result in throttling occurring much sooner than more targetted calls (and you need to let calls finish before issuing new calls, be very careful with queueing multiple curl requests). Once you have been throttled trying the same call over and over will likely increase the length of time throttling occurs (I haven't seen as full day but I have seen several hours before).
I presume (but am not sure) that all microsoftgraph-api calls will internally count towards resource limits, but if you direct onedrive calls against the onedrive-api this will not count against the microsoft-graph limits and may allow the requests you need without throttling.
I would definitely recommend getting a second access token for the direct onedrive api (you can use the same refresh token) and try this approach.
GET https://www.onedrive.com/v1.0/users/:userId/drives
If it is one user in particular that has issues maybe they have exceeded their tenant resources?
I get this message when I query the API for messages on some mailboxes in my organization. It sounds like it's a temporary situation that will be fixed over time, unlike other messages like 400/not found or invalid licenses. Couldn't find any information to confirm/deny this speculation. Is it a temporary situation?
This is a bug in code. For users that don't have mailboxes in O365 cloud, sometimes instead of returning 404, the service ends up returning 503 or 500 with this error. You can safely ignore this error and treat this as a 404 mailbox not found.
For the past two days, I have been facing this issue.
503: Instagram is rate limiting your requests
There are generally two types of query that causes this error. Though there is no discern-able consistency I can find.
GET https://api.instagram.com/v1/users/self/media/recent.json?access_token=<user token>: 503: Instagram is rate limiting your requests.
GET https://api.instagram.com/v1/users/self.json?access_token=<user token>: 503: Instagram is rate limiting your requests.
I have searched the documentation (https://www.instagram.com/developer/) but I was unable to find any references to 503 errors.
The other links I have been looking at is the following.
Instagrm Rate limit issue
https://imranakbar.wordpress.com/2012/09/13/rate-limit-exceeded-instagram-error/
As I am using the instagram-ruby gem, it seems like the service is unavailable?
raise Instagram::ServiceUnavailable, error_message_500(response, "Instagram is rate limiting your requests.")
Refer to this link for more information on instagram-ruby gem
https://github.com/facebookarchive/instagram-ruby-gem/blob/master/lib/faraday/raise_http_exception.rb
I would like to know
(1) if the service unavailable is due to me unknowingly hitting the rate limits and got throttled
or
(2) Instagram is doing some stuff to their servers, causing this error
NOTE: I have sent a report to Instagram on this issue.
HTTP 503 response stands for Service Unavailable. The error message is misleading as it suggest that you are hitting your rate limit. From Instagram's documentation, you can read that hitting rate limit will result in HTTP 429. I believe that in your case it is some kind of overload or maintenance.
You should contact Instagram's support directly.
To compensate for this problem, I have added code to rescue from the 503 error and retry again later on. To avoid retrying indefinitely, the code will also keep tabs of the number of retries and will show an error after a number of retries.
I am trying to resolve a problem with an 3rd party application I am integrating with. Our API access was IP blocked due to a series of errors being raised because of calls we were making to the 3rd party application. After chatting to them they sent me the error that they were receiving in their logs.
A sample request sent is: [REMOVED_IP] - [REMOVED_API_TOKEN] [18/Aug/2015:12:57:42 +0000] "PUT /contacts/5016104701.json HTTP/1.1" 500 38052 "-" "Typhoeus -https://github.com/typhoeus/typhoeus" "[REMOVED_IP]".
According to them
It looks like the particular IP was hitting the url https://github.com/typhoeus/typhoeus several times. Also, we got multiple Nginx 500 Errors for that domain too.
From my understanding the log they sent me is saying that there was an internal server error (500) on their side. I have am guessing that "Typhoeus -https://github.com/typhoeus/typhoeus" is a response header. From my research that could be the effective URL being returned in the response. Something to do with redirection, but I could not find much on it.
My questions are:
Is this an error on their side? I am guessing it's an error in their application.
What is the "Typhoeus -https://github.com/typhoeus/typhoeus" in the response header?
Yes, it seems that the error is on their part.
Typhoeus -https://github.com/typhoeus/typhoeus is the default user agent.
https://github.com/typhoeus/typhoeus/blob/master/lib/typhoeus.rb#L50