When I use the MS Graph api to fetch event deltas for a calendar view or message deltas for a mailbox using the supplied delta token or skip token, I periodically get 503 unknown errors. Multiplied by hundreds of calendars or mailboxes, I get the 503 errors very frequently.
Sometimes, re-fetching without the delta token or skip token, I am able to retrieve the entire dataset rather than just the changes, but that is very slow, and then when I try to incrementally sync using the new delta token, I get a 503 again.
Sometimes, restricting odata.maxpagesize=2 helps alleviate some 503s temporarily, but sometimes it grinds to a failure and still hits the 503.
How can I avoid getting 503 errors?
I can supply request IDs and stuff if someone at Microsoft wants to dig into this.
Related
Our team is developing a simple Angular website that sends a form data to our backend via API. This website will be published under a public IP, so the interaction will be protected with Google reCAPTCHA v3.
Recently we decided to run some stress tests in a pre-productive environment in order to see if everything is stable and works correctly. So we set up a simple JMeter tests group with 100 users and 100 loops. This way we had 10000 requests in total to our API. So, having all that configured, we ran the frontend in order to generate a reCAPTCHA token, executed the action which sends the data to the API and copied the generated token into the JMeter configuration.
The API, before passing the form data to the backend, checks if the token is valid by making a request to “https://www.google.com/recaptcha/api/siteverify”, specifying this token and the secret key generated in the reCAPTCHA admin console.
After executing the JMeter tests, we saw that a certain amount of requests bypass the validation of the token and end up in the backend, while the token has already been used.
What we tried?
Stress test of our API with 10k requests in order to try the validation of an already used reCAPTCHA token.
What we expected to happen?
All the requests to return an error code of 401, beacause the reCAPTCHA token has already been used before and those tokens are single use only (the 401 code is returned by our API if the request to "/siteverify" returns a "success:false" in the response body or a status code other than 200).
What actually resulted?
5% of the requests bypassed the validation and ended up in the backend.
JMeter results
(The 400 bad request errors are returned by the backend, after the validation of the token has already been done, meaning that the token was assumingly valid)
We chequed the logs of our API and we've been able to verify that, in fact, the "/siteverify" requests return a status code of 200 and a response body of "success:true" in those 5% of the tests.
To me, it seems like some kind of balancing problem, maybe some node didn’t have enough time to replicate the status of that token? Or maybe the problem comes from our implementation… Hopefully someone could give us a hint!
I want to reproduce a bug, these are the conditions :
GetStreamingEvents request should fail and preferably get 500 error from office365/exchange
The Resync request to send GetStreamingEvents periodically should keep failing.
Here is what I have tried so far :
I have tried to remove X-AnchorMailbox header and not send any Impersonation header but my syncing still works and GetStreamingEvents is a success.
On Exchange I moved users from one Database to another and Streaming events failed for a while till migration was in progress but it succeeded eventually.
Tried disabling Admin mailbox on exchange but that too didn't lead to any error.
Of course I tried to hardcode exchange's response but this hack is not 100% reliable.
I have Exchange2019 (acting as office365). I just want to lose my subscriptions somehow through Streaming notification mechanism of EWS. Please help me in this - what can I tweak on exchange or in my request to get streaming event failure.
After the most recent Firefox update (68.0), I am having problems with persistent session data.
When a user logs in, as the page loads, there are various expected CSP violations that send a POST request containing the violation report to the path report-uri directive contains.
Subsequent API GET requests to retrieve user data returns a 403 Forbidden, which (by design) redirects the user back to the login page. Since the user is logged in already, same API requests are sent that result in another 403, which leads to an infinite loop until after an arbitrary number of loops API requests return 200 OK.
All requests (both POST and GET) before and after the update are the same.
It seems to me that the fact that there are CSP report POST requests before the API requests changes something related to the session, which is used by the back-end to determine if the user has the correct privileges.
Could Firefox have changed something about the way it handles CSP report-uri requests or their responses change with the update?
What would be a good way to approach this problem?
Firefox has just been updated to version 68.0.1. The update seems to have fixed this problem. Release notes don't seem to be related to this in a way I can make sense, but regardless, the problem is solved.
So my colleague ran into this error while attempting to add http referrers to our javascript maps api key. Our app needs to be able to hit the api from our client domains, and there are well over 1200 of them. Has anyone hit this limit, if so, how have you surpassed it?
I'm getting the following error intermittently when invoking the custom search api from a server side setup:
HttpError 403 when requesting https://www.googleapis.com/customsearch/v1?q=John+Doe+john%40simpler.com&alt=json&cx=&key= returned "There is a per-IP or per-Referer restriction configured on your API key and the request does not match these restrictions. Please use the Google Developers Console to update your API key configuration if request from this IP or referer should be allowed.
I'm using a server api key, and have confirmed that the configured server ip address is correct. And about 50% of the time my request come back fine, too. I'm issuing the request from the server like this:
service = build("customsearch", "v1",
developerKey=api_key)
custom_search_context = <my_context>
res = service.cse().list(
q=search_query_string,
cx=custom_search_context,
).execute()
My requests per sec are well with in the configured limit of 10/sec and daily purchased limit of 5000 requests.
One more thing I noticed is that Google counts a forbidden request towards the daily limit, too.
Any pointers on why I'm being presented with the error only intermittently would be very helpful
The error can be raised when you're exceeding a request/second limit. Can you confirm that your request rate is below your configured user rate limit? It might be worth noting that the limit is enforced even if you don't explicitly provide a user value in your requests.