I use the youtube bulk reports (youtube analytics and reporting api) and get few of the reports on a daily basis , by first listing the reports available for the jobs I have defined and then downloading. The API call made to list the reports available "https://youtubereporting.googleapis.com/v1/jobs/{jobId}/reports" is consistently giving 500, Internal error for the whole day ( 5/14/2017) , where as the query to list jobs does give the required list of jobs (https://youtubereporting.googleapis.com/v1/jobs). I have tried this from my code which has been working for past several months as well as from the Oath Playground tool.
Questions
(a) How does one get more information when this happens, the error in documentation just asks to try later
(b) Is there a place we can see the status of youtube-analytics-api health, so that we know there is a production issue , if any
Related
I have recently encountered a problem with adding new tasks to Google-Tasks.
Both the Google Calendar integration (in any browser) and the Google Tasks App (on Android - Galaxy S9+) report an error whenever I try to add a new task.
On Google Calendar I get the error message:
"Reverting to the latest state because there was a problem."
On the Google Tasks App I get the error message:
"Unknown Server Error. Please try again later"
neither of which is very informative about how to solve the problem.
I did some further investigation via the Google-Tasks-API and found that I can still delete and modify tasks, but whenever I try to insert a new task into a list I get the following 403 error message from the API:
{
"error": {
"errors": [
{
"domain": "usageLimits",
"reason": "quotaExceeded",
"message": "Quota Exceeded"
}
],
"code": 403,
"message": "Quota Exceeded"
}
}
However, I checked my Google-Tasks API quotas at:
https://console.developers.google.com/iam-admin/quotas
and I don't seem to be anywhere near any of the usages limits, so I don't really understand why I am getting this error message.
I've been using Google Tasks successfully for several years, including using the Google-Tasks-API to manage bulk updates, but have not changed any of my set-up recently. Is it possible I have stumbled into some global limit on the number of tasks permitted, or a limit on the number of tasks per list? I do have quite a lot of long-running tasks (I have a list to track dev ideas for some software that I maintain).
Any help would be greatly appreciated as I use Google Tasks to organise almost every aspect of my work-life and being without this is rather disruptive to my productivity.
It is rather frustrating that this issue seems to be affecting my normal day-to-day use of Google Calendar Tasks and the Google-Tasks App (I could have coped if it were just my script that uses the API that was not working).
I'm using Facebook Ad Library API but I can't figure out how rate limit works.
On the application dashboard under "Application-Level Rate Limiting" the chart is always showing zero calls and when I make a new API call the header just shows this (the 'call_count' field is missing):
{
'total_time' : 0,
'total_cputime' : 0
}
I've read on a report by Mozilla developers that there is a rate limit (they were blocked a few times), someone can help?
Thanks
I was running into a similar issue and worked out the following solution:
You can see the current usage of your rate limit for the Ad Library API by looking at the "object_count_pct" in the header. API calls are blocked once it reaches a value of 100 (%).
Avoiding the limit is then possible by pausing calls at a certain percentage until the object_count_pct goes down again. You can also build your API calls so that they use the "estimated_time_to_regain_access" value to restart the calls after Facebook unblocks your app.
Unfortunately I could not find any documentation regarding the actual rate limit or at what speed the object_count_pct goes down once calls to the API are halted. The 200 calls per hour as stated in the official docs is definitively not accurate as I have managed to make over 5.000 calls in ca. 8 hours.
Currently it looks like the lice SDK returns error 500 for all request. Also the interactive SDK Microsoft provides here returns the same error:
http://isdk.dev.live.com/dev/isdk/ISDK.aspx?category=scenarioGroup_core_concepts&index=1
My application work without any changes for over 24 months. Has someone any more details or a workaround?
Update: I tried the following API calls both with the same result:
https://apis.live.net/v5.0/me?access_token=#Token#
https://apis.live.net/v5.0/me/picture?access_token=#Token#
Finally, and after a very long downtime (more than 20 hours) the Live API is up & running again.
Unfortunately, there is not even an official announcement from Microsoft.
Up & Running
Have the same problem and all of my apps worked before for very long time.
I'm using LiveSDK 5.6 and getting successful response for LiveAuthClient.LoginAsync with the following scopes: "wl.signin", "wl.basic", "wl.contacts_photos", "wl.contacts_skydrive",
"wl.skydrive_update"
LoginAsync returns LiveLoginResult object where:
Status = Connected
Session = {Microsoft.Live.LiveConnectSession} with AccessToken
but when app trying to call
Session (LiveConnectClient) object with GetAsync ("/me")
I'm getting the following exception
[Microsoft.Live.LiveConnectException] = {"An error occurred while retrieving the resource. Try again later."}
ErrorCode = "server_internal_error"
The OneDrive service experienced a service outage on the 9th, you can see from this 3rd party site for an idea of the timeline. We did not communicate this issue well to you and other developers that have come to expect excellence from OneDrive.
It is the start of a long weekend and I do not have more answers for you at this time, I'll circle back next week with better details on what to do in the future.
The Live Connect API that the LiveSDK works in conjunction with has been replaced by the OneDrive API, which also has SDKs for most major platforms. You will see major performance improvements and a larger feature set such as a modern sync API available for you with this new API if you transition to it.
Currently i am using following FQL query :-
https://api.facebook.com/method/fql.query?query=select post_id,likes FROM stream WHERE source_id=XXXXXXXX LIMIT 0,10000&access_token=XXXXXXXXXXXXX&format=json
I have two Facebook Accounts / pages & able to download data using above API. Able to retrieve posts & post likes count.
But, from last three days, for one Facebook account above FQL query is not working. it is returning message :- "error": "Request failed" . For other account it is working fine.
For each facebook Account / pages i have generated separate Access Tokens.
But, if i update limit from : -
Limit 0,50
Limit 50,100
then it is working & returning posts from page but not returning all post which i have previously getting from Limit 0,10000
Please help me, if any one have idea about this issue ?
Thanks
Facebook will cancel queries which take too long or too many resources to execute. In general, I would never use LIMITs which are that high. There's a high probability that they will fail, and you can't really incfuence the query execution "load" other than setting the LIMIT to a reasonable number (which means implementing a paging mechanism).
Separate issue raised with Google by st...#ditoweb.com here (issue 2391)
We have an iframe-based spreadsheet form on a website (http://www.monarch-equestrian.co.uk/brochurerequest.html) which is set to generate emails with attached PDF's to respondents.
Over the past few days, this has been generating an error notification - "You do not have permission to call getActiveSpreadsheet". The script, triggered on submission, has been working perfectly - however the spreadsheet had grown to 1387 rows so we archived it and deleted most of the records in the original (in case we had reached the limit allowed and so we wouldn't have to create a new spreadsheet etc).
The question is, even though the spreadsheet is presumably now within data limits and all the settings are unchanged, why are we still getting the error?
According to the reported issue noted in the question, this was fixed Feb 25, 2013.