We have a sales tracker app. In this app, we collect all analytic data from 5 different analytic accounts (websites) and creating reports. It was working till today morning itself. Now it shows some errors like 500 Backend Error:
PHP Fatal error: Uncaught Google_Service_Exception: {"error":{"errors":[{"domain":"global","reason":"backendError","message":"Backend Error"}],"code":500,"message":"Backend Error"}}
500 errors are catch all errors that normally mean that there is something on the servers end that is the issue. If you check the documentation you will see the above comment. Google says that they dont want you to retry that error. However if you scroll down a bit more in the documentation you will find this section.
However we find the following as well.
However there is nothing with both "code":500,"message":"Backend Error"
backoff
There are a number of error messages where backoff would work.
With a python example that includes
This is because the Google analytics api is slightly different than the other Google apis the way it returns errors is not the same and in most cases its better. The reason for this is that backend error can be cause by flood protection. Not often but it can happen mostly around the hour. You should never run a large script on the hour because then you are competing with everyone that has cron jobs set up to extract data every hour.
I normally only use backoff for 'userRateLimitExceeded', 'quotaExceeded', 'internalServerError' errors not for 'backendError' but Google is stating it in their documentation so it may be worth a shot.
In the mean time i am going to send an email off to the team to get some clarification on the documentation.
500,"message":"Backend Error"
As for the message above i have seen this a few times and its often related to an issue on Googles end. Give back off a try while i wait to hear back from the team.
Related
We have an app which uses different APIs like dv360 and google ads. The issue is that we are facing Daily limit exceeded exception very frequently. We have checked project dashboard to cross verify if we are actually hitting the quota. However, we found that we are not hitting the allowed quota for any of these APIs but still we are getting this error.
Can someone point out what can be the reason for the error ?
Thanks in advance.
The first thing that you need to understand is that the dashboard is not perfect it is not accurate by any sense of the word. it is an estimate and it is not real-time.
What you should check is the error message that you are getting this is the truth. You would not get that error message unless you where hitting the quota limit.
The first thing that you should do is check your code and ensure that you are not hitting the Usage Limits defined on that page.
if you are hitting the limit and you cant reduce the number of requests you are making then you will need to request a quota extension.
This is strange we have started receiving too many per day (nearly 300-500 times)
googleapi: Error 500: Internal error encountered., backendError
while calling Admin SDK Directory API. https://developers.google.com/admin-sdk/directory
Google chat support for API is removed and Facing issue with how to address the problem. Our rate limit and query calls are way in the limits. We query Admin SDK as a cronjob schedule.
Is there a way we can debug 500 errors for AdminSDK
Is there any information regarding which deployment Region of Google is more capable to handle load?
No error on console
Logs error
Contact Workspace Support or File a Bug
As DalmTo pointed out, 500 errors are usually out of your control. Especially in this case since you are calling Google's servers.
The best option to debug these errors is probably contacting support directly. You can find the corresponding contact information for your Workspace account on this page.
https://support.google.com/a/answer/1047213?hl=en
If you are able to regularly reproduce this and you think its a bug, fill out the template here:
https://issuetracker.google.com/issues/new?component=191635&template=824102
Ensure to include your code, complete reproduction steps, some evidence/statistics of the failures, and any other information you can give.
This usually happens when the Google Cloud Platform service account used for authentication was created after the in-app products.
To solve this, make a trivial edit to your in-app products in the Google Play Console. For example, add a temporary tag. Then try again to make the request and it should succeed.
By the way, the same is true for the purchases.voidedpurchases which reports an "insufficient permissions" error.
I'm having very high latencies (5min) on google sheets append values requests. This is starting to happen more and more. As I have been doing the same requests for months (and same volume) I don't think it is because of my inputs.
Checking google support they suggested to create a topic here. Not sure if a google engineer will comment or if some other end users are experiencing the same problem?
In the charts you see a lot of errors, these are the errors I get: "append_sheet: googleapi: Error 500: Internal error encountered., backendError". So nothing useful :s.
Greetings,
PJ
Today I try to enable Google+ API on API Manager and it said
Error: failed to do requirement checks
What wrong? I just disable it and I want to re-enable again.
This is most likely an outage on Google Developer console even though I am not seeing it on the status page.
There for the fastest way to get it resolved will be to go to the upper right hand corner in google developer console look for the !. Send feed back.
You cant feed back the actually error as its a popup but you can feed back from the screen before you attempt to enable an error.
I am having the same problem. Perhaps it is an outage.
Evidence: I count 5 people here so far that have the issue, and no google results for that exact error message. "Error: failed to do requirement checks" That means, it's a new error, and google's crawler hasn't had time to scrape even this question yet.
It's okay now, I just re-enabling the API and it works.
I think its outage
I'm trying to use the garb gem to access data from the Google analytics API and find that http requests using garb work just fine from a Linode account, but are refused from home (Comcast). Is Google rejecting some kinds of http requests from certain ISPs, or am I just doing something wrong? Simple example is below:
require 'garb'
Garb::Session.login('XXXXXX#gmail.com', 'XXXXXX')
#profile = Garb::Profile.all.first
#report = Garb::Report.new(#profile)
#report.metrics :visits
puts #report.results
This give => [#<OpenStruct visits="21">] on my Linode, but the exact same thing run from my home ISP gives:
Garb::DataRequest::ClientError: "<errorsxmlns=.........
Which is raised here in garb:
def send_request
response = if #session.single_user?
single_user_request
elsif #session.oauth_user?
oauth_user_request
end
raise ClientError, response.body.inspect unless response.kind_of?(Net::HTTPSuccess)
response
end
The initial session login works just fine from both IPs. The error is only thrown when results are requested. Is there anything I can do to fix this? I haven't (yet) verified that I get exactly the same behavior going through clientlogin/data requests by hand. I'm pretty convinced it is not a gem issue, but an IP-related one--perhaps something to do with Google web services quota policies--but I'm willing to entertain all possible solutions.
Thanks,
Orion
You've probably made too many calls to google in a short space of time. I haven't seen it happen with Garb, but I've seen it happen when using an API to scrape search results pages. Google notices and flags your IP. Try browsing to google.com and running a normal google search from the ip that's blocked, you'll probably be required to enter a captcha. They probably block API calls from that IP at this stage, you'll get cleared eventually after a few days I think.
Jeremy's probably right.
Google Analytics API has multiple quotas you need to worry about. See here their list here. I've hit the 10 queries per second per IP address quota and/or the 10 concurrent requests per profile before. I also saw 4 concurrent requests per IP address somewhere.
You should post the full error message Garb gives you next time, since those have actually helped me figure out what caused it in the past.
Also, these quotas are for projects sending registered API keys along with their requests. If you're not, the quotas are much lower. I hit the quota for an unregistered project before. Registering your project is fairly easy, and you just add the following line
Garb::Session.api_key = 'API_KEY'
to your code (I'm using Sija's fork) before the Garb::Session.login line.
Another thing, once you register your project, go to Quotas page on the API console and click the "Set per-user limits" and up that from the default 1.0 to the max 10.0 requests/second/user. If you click "Request more" they give some tips for optimizing your calls/timing as to not hit the limit.