We've had a lot of these errors from only one of our DCs - running the same code as others globally.
For example:
2017/03/31 13:22:03 Error sending request to BigQuery (attempt 1 of 3): Post https://www.googleapis.com/bigquery/v2/projects/coull-delta/datasets/demand/tables/table_name/insertAll?alt=json: stream error: stream ID 1221; PROTOCOL_ERROR
It uses the Big Query Go package from google - https://godoc.org/google.golang.org/api
Anyone got any ideas? Seen this before? As I said, exactly the same code running in other places with no issue.
Related
Ive got a problem when trying to create a new visual for a query (source is Google BigQuery).
I'm using a similar query, that is already working (but with an extra filter), making the new query take a little longer.
It runs for about 10 minutes, and return this error message:
Details: "ODBC: ERROR[HY000] [Simba][BigQuery] (115) Operation timeout.PollJob"
So add an time limit parameter: "connect timeout=10000", but it doesnt work neither.
driver={Simba ODBC Driver for Google BigQuery};oauthmechanism=1;refreshtoken=TOKEN;catalog=mm-datamart-kd;connect timeout=10000
If someone get the error or have a solution for this error message. I would be grateful if you give me your advised.
Thanks!
I am using the Microsoft Outlook REST API to synchronize messages in a folder using skipTokens with the Prefer: odata.track-changes header.
After 62 successful rounds of results, I get an error 500 ErrorInternalServerError with the message Unable to cast object of type 'LegacyPagingToken' to type 'Microsoft.Exchange.Services.OData.Model.SkipToken'
I have tried:
Retrying the same query (https://outlook.office.com/api/v2.0/me/MailFolders/Inbox/messages/?%24skipToken=1BWUA9eXs5dN89tPsr_FOvtzINQAA0Cwk5o), which results in the same error
Restarting the sync, which results in the same error at the same point
Adding a new message to the Inbox and restarting the sync, which results in the same error at the same point
Moving the messages from that part of the sync to another folder (in case the messages themselves were causing the problem), which results in the same error at the same point
Has anybody run into this error or have suggestions on what might cause it or workarounds?
It looks like the issue was on my end while parsing the skipToken from the #odata.nextLink response. The token in the original question is invalid - the actual skipToken passed back from the API had -AAAA on the end. After 63 queries, in which the skipToken increments, the Base64 encoded form started using characters the regexp I was using didn't find. Switching from a \w regexp to a proper URL parser solved the problem.
I'm currently coding an app that utilizes Parse as a backend, but have run into a '124' error. I admit that I do a lot in my cloud functions, but, from what I've observed, it doesn't appear over 15 seconds. Could someone please confirm this? Below is the output.
E2015-03-06T03:49:52.644Z] v286: Ran cloud function createEvent for
user puZNjFVfSm with:
Input:
{"RSVPDate":{"__type":"Date","iso":"2015-03-06T04:49:52.000Z"},"description":"Sample event to showcase
functionality","group":{"max":5,"min":4},"max":50,"reoccur":{"day":1,"month":1,"stop":{"__type":"Date","iso":"2015-03-06T04:49:52.000Z"},"week":1},"title":"SampleFCFS"}
Failed with: Execution timed out I2015-03-06T03:49:52.716Z] begin
I2015-03-06T03:49:52.717Z] creating Event - initial checks completed
I2015-03-06T03:49:52.718Z] Finished advanced checks
I2015-03-06T03:49:52.719Z] Event creation start
I2015-03-06T03:49:52.770Z] begin event creation
I2015-03-06T03:49:52.873Z] Finding role: company_employee_z0Zx39OyuY
I2015-03-06T03:49:52.875Z] Added and secured event
I2015-03-06T03:49:52.931Z] attaching role to 425Qy9v9e4
I2015-03-06T03:49:52.934Z] Adding participant
From what I can tell, it looks like I'm only getting 300Z (is that milliseconds?) on all my runs. Shouldn't I be getting 15 seconds?
Update: I found that the issue was caused by using the addUnique function of Parse Objects with an array of pointers. By inserting ids instead of pointers, the issue was resolved.
Thank you for your help.
My code fetches calendar events using service.events().list() with the following parameters:
timeMax: 2015-11-13T04:12:44.263000Z
timeMin: 2014-05-17T04:12:44.263000Z
updatedMin: 2014-11-12T14:56:20.395000Z # = yesterday
I know there's a limit on the updatedMin param that prevents it to be too far in the past, but lately I get the following error even when updatedMin is yesterday:
The requested minimum modification time lies too far in the past.
Everywhere this error is mentioned, they are talking about a limit that is approx. 20 days in the past, certainly not one day.
Any ideas what is causing this error?
#Tzach, I tried the above query in API explorer with the same values and it returned the results without any error unless its greater than 20days. As Luc said, better to switch to syncTokens which saves the bandwidth.
I've faced with the strange situation. When connected to the Google Play Services I request the array of Achievements calling GamesClient.loadAchievements(this, true); In onAchievementsLoaded() method I see that all my achievements are of correct type. To ensure I call Achievement.getType() and for each of my achievement it returns Achievement.TYPE_INCREMENTAL.
The problem arrives when I'm trying to increment any of my achievements by 1 using
GamesClient.incrementAchievementImmediate(this, id, 1);
In onAchievementUpdated() I receive statusCode 3002 (STATUS_ACHIEVEMENT_NOT_INCREMENTAL).
I'm in total frustration. The matter is that all achievements initially were of other type (not incremental), but then in dev console the type has been changed. 2 days passed since that.
It was my mistake, I've reviewed my code once again and found that I was sending wrong achievement id. But Google guys do ugly too - they report wrong status code for that. The response should be STATUS_ACHIEVEMENT_UNKNOWN, according to documentation. I was receiving 3002 STATUS_ACHIEVEMENT_NOT_INCREMENTAL instead, which confused me a lot.