We are collecting Google Analytics data off of the GA API for various accounts. In most instances it works without a problem, but for one account we keep getting an unknown 502 error with the following response:
<p><b>502.</b> <ins>That's an error.</ins>\n <p>The server encountered a temporary error and could not complete your request.<p>Please try again in 30 seconds. <ins>That's all we know.</ins>\n"enter code here
Once we hit 10 of these (as per the error limit) we are kicked into 429s because we've reached our error quota limit.
There is no proxy in (except ostensibly on the GA side) between us and this works without problem for most accounts but this one.
This sounds like a bug that should be sent to the issues tracker.
There are a few bugs open bugs that are about 502 errors as well. Your issue may be the same as one of these.
Related
We are building a tool to off-board existing employees, including clearing their calendars of all existing events. When querying the /calendars/{calendarID}/events/ endpoint, we are occasionally getting a 500 - Stack limit exceeded error. We're only generating a few dozen to hundred requests, so we don't seem to be hitting any rate limits, which appear to be 10k per day; additionally, it's only intermittent, rather than a failing continuously, as a rate limit would generally cause. Anyone familiar with this error?
You can find all the Calendar API related errors by checking this link here.
As for the error message 500 - Stack limit exceeded you are receiving, it looks like the issue might in fact be coming from somewhere else.
You can also test the Calendar API by using the Calendar API Reference here.
Reference
Calendar API Errors;
Calendar API Events:get.
Yesterday (June 22nd, 2020) at 2pm Pacific, we started getting back 429 errors for all our requests to the Google Calendar V3 API. The body returned is html that asks the user to fill out a captcha.
These errors are not the standard 403 errors you get when you hit Google Calendar quota limits. Also, we checked, and we haven't hit Google Calendar API limits. So I assume this rate limiting is happening at a different level.
We fixed the issue yesterday by changing the IP address that we are sending these requests from. Unfortunately, again at 2pm today (June 23rd, 2020) the problem started happening again.
We are not getting these errors back from the Google Address Book API. It just seems to be Google Calendar API.
Has anyone else noticed 429 errors from Google Calendar API over the last few days? Or is Google listening and might be able to help?
Thanks!
There seems to be a new issue that has been filed on June 19th on Google's Public Issue Tracker
Seems like several users are affected, but the issue is reported to be currently investigated.
I recommend you to "star" the issue in order to stay up to date to its current state.
In the meantime, since the 429 error seems to be related to rateLimitExceeded, you can try to workaround in the same way like for 403 errors, that is e.g. implement exponential backoff as described in the documentation.
I had had the same issue with Google Calendar API today. HTTP Code 426 and HTML page with captcha in the response body.
This decision had helped me
If you use python you need to replace
build('calendar', 'v3', http=creds.authorize(Http()))
with:
DISCOVERY_DOC = json.load(open(os.path.join(SCRIPT_DIR, 'calendar-api.json')))
googleapiclient.discovery.build_from_document(DISCOVERY_DOC,http=creds.authorize(Http()))
calendar-api.json you can download from this link
We are uploading a new version of our website.
For various reasons, some pages that exists on the older version still aren't ready for the new version and we need to temporarily take them off.
Which HTTP status should we return for these pages considered they will be up and running again within several days.
Is using ServiceUnavailable = 503 only for these pages the right way or will it have negative impact on the entire website?
(Using ASP.NET in case it's related in some way...)
The status code 503 seems to be the best choice here:
The 503 (Service Unavailable) status code indicates that the server is currently unable to handle the request due to a temporary overload or scheduled maintenance, which will likely be alleviated after some delay.
It shouldn’t be relevant that it’s not due to overload or maintenance in your case. What is relevant is that it’s your fault (hence a status code from the 5xx class), and that it’s temporary (hence 503), so there’s no need to let them know the real reason.
While 503 is typically used for the whole site, I can see no reason why it shouldn’t be used for specific pages only. A possible drawback: If a bot successively crawls a few documents that give 503, it might think that the whole site is affected and stop crawling for now.
If you know when the page will be available again, you can send the Retry-After header:
When sent with a 503 (Service Unavailable) response, Retry-After indicates how long the service is expected to be unavailable to the client.
(FWIW, the Googlebot seems to support this.)
In the post Website outages and blackouts the right way (by a Google employee at the time), my assumptions are confirmed as far as Google Search is concerned: 503 should also be used for specific pages only; crawling rate might be affected if Googlebot gets many 503 answers.
We have a script updating Domain Shared Contacts for our tenant that runs every morning. Today, the insert requests started failing. Google is returning error code 500, which according to documentation is an 'unrecognized error'.
I'm not finding anything regarding an API outage currently going on, nor am I seeing anything relating to an API change taking effect today.
I recreated the request with curl hoping to get more info, but still just receive "500 Internal Server Error".
Anyone else seeing this? Anyone aware of an internal problem at Google, or an API change which just took effect?
Thanks for any help.
EDIT:
The issue seems to be resolved. Hopefully it has for others with this problem as well. Thanks to Google for addressing this.
Yes unfortunately this problem started yesterday see
Exception while adding contact in google.Internal server Error
I urge you to raise a Case with Google Support
I've been recently fixing my application that apparently reached some GA quota
limitations and I've found a couple of things that were not clear to
me:
Does the 4 concurrent requests limitation apply per application,
per web property or anything else?
If we break the 10 requests in any given 1-second period or 4
concurrent requests limitation, how long does it take before GA stops
responding with 503 ServiceUnavailable error?
Does quota per application refer to the application name string
only? We are running two different web application using different GA
application string. Both apps connect GA API from the same IP address.
Can we expect the quota per application is calculated for each
application string separately in this case?
Are the status codes sent with 503 ServiceUnavailable response
documented anywhere? Can we be sure that rateLimitExceeded refers to
the 10 requests per second limitation? How can I found out the cause
of an 503 response?
Btw is it possible that a stronger quota restrictions than documented
may take effect sometimes?
For example, is it possible that GA replies with 503 ServiceUnavailable
response just after 6 fast but subsequent requests or just because of any
other undesired behavior of a client application that's not included
in the documentation?
Regards,
Pavel
It's just been answered by Nick in the GA Google Group.
Main points: the 10 qps and 4 parallel requests limitation count per IP, even an application running on a different machine in the same network may be counted.
I've submitted a documentation bugreport to the GData issue tracker.