We are using Google.apis Version 1.36.1 SDK in order to create service account keys for GCP Service accounts.
When we reach maximum amount of keys (10) instead of getting a valid error message / error code we recieve a general 400 error code with a "Precondition check failed." message.
We used to get error code 429 indicating we have reached maximum amount of keys.
Current GoogleApiException object :
Google.GoogleApiException: Google.Apis.Requests.RequestError
Precondition check failed. [400]
Errors [
Message[Precondition check failed.] Location[ - ] Reason[failedPrecondition] Domain[global]
]
The current return code does not provide us with enough information, Is there any other way for us to know the reason of the failure ?
This error message is also related to limits. You can take the official documentation for the Classroom API as an example.
I have found myself in a similar situation where we were deleting service account keys to immediately create new ones. We were getting the same error because there is a delay on the system where it can take from 60-90 seconds to delete the key for you to be able to create it again.
Related
I have about 4000 files (avg ~7MB each) input.
My pipeline always failed on the step CoGroupByKey when the data size reach about 4GB.
I tried to limit only use 300 file then it run just fine.
In case of fail, the logs on GCP dataflow only show:
Workflow failed. Causes: S24:CoGroup Geo data/GroupByKey/Read+CoGroup Geo data/GroupByKey/GroupByWindow+CoGroup Geo data/Map(_merge_tagged_vals_under_key) failed., The job failed because a work item has failed 4 times. Look in previous log entries for the cause of each one of the 4 failures. For more information, see https://cloud.google.com/dataflow/docs/guides/common-errors. The work item was attempted on these workers:
store-migration-10212040-aoi4-harness-m7j7
Root cause: The worker lost contact with the service.,
store-migration-xxxxx
Root cause: The worker lost contact with the service.,
store-migration-xxxxx
Root cause: The worker lost contact with the service.,
store-migration-xxxxx
Root cause: The worker lost contact with the service.
I digging through all logs in Logs Explorer. Nothing else indicate error other than the above, even my logging.info and try...except code.
Think this relate to the memory of the instances but I didn't digging into that direction. Because it kindna what I don't want to worry about when I am using GCP services.
Thanks.
I get a 410 when syncing messages:
{\"code\":\"SyncStateNotFound\",\"message\":\"The sync state
generation is not found; generation=1;[highest=4][4][2][3].\"}
This only occurs when syncing messages for select mailfolders on select accounts. It occurs when making a post-initial sync using the relevant delta token. I can recreate this via making
GET https://outlook.office365.com/api/v2.0/me/MailFolders('{folder_id}')/messages/?$deltaToken={delta_token}
In Microsoft's Outlook Sandbox.
Here are the literal steps it takes to reproduce deterministically:
1) Initial Message Sync:
GET https://outlook.office365.com/api/v2.0/me/MailFolders('{folder_id}')/messages
2) Sync with initial delta token:
GET https://outlook.office365.com/api/v2.0/me/MailFolders('{folder_id}')/messages/?$deltaToken={delta_token}
3) Sync with skip token until delta token:
GET https://outlook.office365.com/api/v2.0/me/MailFolders('{folder_id}')/messages/?$skipToken={skip_token}
4) ERROR OCCURS HERE: Mailfolder receives update, so I re-sync messages with delta token from (3). The call below throws a 410 and I can't sync messages.
GET https://outlook.office365.com/api/v2.0/me/MailFolders('{folder_id}')/messages/?$deltaToken={delta_token}
To reiterate: I've isolated this to just testing in the Outlook sandbox, and it still occurs. Testing as in making the GET call to sync (i.e., make perform (2)) using the deltaToken from (3) and its corresponding folderId as query parameters.
Dumb Mistake: Passed in initial delta token as opposed to current.
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 attempting to upload AIR test 2C via the IRS UI web portal and received the following submission error: "The manifest file does not match our current schema. In particular, our system has detected a potential issue with the following element(s)" OriginalReceiptID
Here's our manifest file:
top portion of our manifest file
Can anyone find the errors of my ways?
You need to provide the OriginalReceiptId (on the Manifest) only when sending a Replacement record type for a previously "Rejected" Transmission.
The OriginalUniqueSubmissionId (on the 1094-C) should be provided only when sending a Replacement record type for a previously "Rejected" Submission.
Note: You will receive Transmission-level error if you include both the OriginalReceiptId and OriginalUniqueSubmissionId. The type of rejection dictates which one is needed to be used. The Type of Rejection is caused by either the Transmission or Submission, and is defined by the reason for the rejection and the structure of the Error Data File received from the status response.
CorrectedUniqueSubmissionId on the 1094-C is used when sending a
Correction record type for a previously "Accepted" or "Accepted with Errors" 1094-C record.
CorrectedUniqueRecordId on the 1095-C is used when sending a
Correction record type for a previously "Accepted" or "Accepted with Errors" 1095-C record.
I don't think you need original receipt id for the correction files, it is for rejected files. refer to IRS air composition referece guide at https://www.irs.gov/pub/irs-pdf/p5165.pdf
I'm getting error for "SNMPv3" of invalid engine ID? what causes this error usually?
it perfectly works when i select no auth,no priv. but for other two options of auth,no priv and auth,priv it gives error of invalid engine id.
ManageEngine MibBrowser supports auto-discovery of SnmpEngineID, EngineBoots and EngineTime from an Authoritative SNMP Engine.
If user has enabled the "Set EngineID For Adding V3 entry" and entered SNMPV3 user details with EngineID parameter, MibBrowser displays the message received from Agent.
As per RFC3414, If the value of the msgAuthoritativeEngineID
field in the securityParameters is unknown then:
a) a non-authoritative SNMP engine that performs discovery may
optionally create a new entry in its Local Configuration Datastore
(LCD) and continue processing;
or
b) the usmStatsUnknownEngineIDs counter is incremented, and an error
indication (unknownEngineID) together with the OID and value of the
incremented counter are returned to the calling module.
Note in the event that a zero-length or other illegally sized
msgAuthoritativeEngineID is received,b) should be chosen to facilitate
engineID discovery. Otherwise, the choice between a) and b) is an
implementation issue.
If Authoritative SNMP Engine returns "unKnownEngineID OID"(.1.3.6.1.6.3.15.1.1.4.0) with incremental counter value to manager. Then, Mibbrowser displays the "Invalid EngineID" error.
Regards,
ManageEngine