Seeing this error when trying to write the tests. How to configure earlgrey to not track network calls at all?
Exception Details: Error Trace: [
{
"Description": "Failed to execute block because idling resources below are busy.",
"Description Glossary": {
"GREYAppStateTracker": "Waiting for network requests to finish. By default, EarlGrey tracks all network requests. To change this behavior, refer to GREYConfiguration.
If you know the link that you'd like to not be tracked, then you can use the blacklist regex configuration.
https://github.com/google/EarlGrey/blob/91c27bb8a15e723df974f620f7f576a30a6a7484/Tests/UnitTests/Sources/NSURL%2BGREYAdditionsTest.m#L43
Related
I recently updated our CDK code to move our OpenSearch cluster from version 1.3 to 2.3. The cluster itself seems to have upgraded to a healthy state and is still accessible / usable by our application, but CloudFormation failed when attempting to update our domain resource with:
Resource handler returned message: "Resource handler returned message: "Invalid request provided: DP Nodes are OOS, Tags operation is not allowed"
This kicked the stack into UPDATE_ROLLBACK_FAILED, which is not allowed. The cluster cannot be downgraded back to 1.3.
I'm struggling to find any information about this error it's kicking out and not quite sure how to resolve it to unblock the CloudFormation stack.
Things I have tried:
Digging through CloudWatch logs only revealed information pertaining to queries.
Forcing the rollback to occur without Domain resource. This got me back to an UPDATE_COMPLETE state, but each subsequent deploy of this stack will cause it to fail again since the core issue is not resolved.
This was an odd presentation of a permissions issue. As I was reading through some docs, I stumbled upon this section, which discusses changes to tag-based access control.
This lead me start looking into CloudTrail a bit and stumbled upon the exact error that was firing when this deploy happened. It was a little odd because the assumed role granted admin access to CloudFormation, but the last line of this event record caught my eye:
"sourceIPAddress": "cloudformation.amazonaws.com",
"userAgent": "cloudformation.amazonaws.com",
"errorCode": "ValidationException",
"errorMessage": "DP Nodes are OOS, Tags operation is not allowed",
"eventSource": "es.amazonaws.com",
Upon adding es.amazonaws.com to the trust relationship of that role, the deploy fully re-ran successfully.
Hopefully this helps someone else.
In my workflows and activities, I’d like to log some messages for debugging purposes.
I saw the cadence.GetLogger(ctx).Info() function, but don’t know where to find the logs.
Go Client:
You can use the following in the workflow code:
cadence.GetLogger(ctx).Info(...)
In the activity code, you should use the following:
cadence.GetActivityLogger(ctx).Info(...)
By default, the logger will write to console, which may be sufficient for development purposes. However, you should log to a file if you need the logs in production, too. Here is how to setup your cadence worker to do it:
workerOptions := cadence.WorkerOptions{
Logger: myLogger,
}
worker := cadence.NewWorker(service, domain, taskList, workerOptions)
The Cadence client uses zap as the logging framework. You can create the zap logger and specify the log file path per your needs. Check out the zap documentation to learn more about configuring the logs.
Java Client
The Java client uses slf4j for logging. You can get the logger instance by calling Workflow.getLogger() and configure it in logback.xml as usual.
VSTS,
How does one configure VSTS to never auto-disable ServiceHooks that encounter errors? Looking thru the UI, there's no checkbox for 'always run, regardless of errors'.
Occasionally, we have to take-down the receiving service for maintenance, we need VSTS to continue to send the request regardless of any errors encountered (past or present).
No, there isn’t the way to configure it to never auto disable service hooks that encounter errors.
Also, continue to send the request regardless of any errors encountered (past or present) will affect the performance.
You can build a app (e.g. windows service) to check and enable web hooks through REST API: Update a subscription.
For example:
Put https://[account].visualstudio.com/_apis/hooks/subscriptions/[subscription id]?api-version=1.0
Body (Content-Type:application/json)
{
"publisherId": "tfs",
"eventType": "build.complete",
"resourceVersion": "1.0-preview.1",
"consumerId": "webHooks",
"consumerActionId": "httpRequest",
"scope":1,
"status":0,
"publisherInputs": {
"buildStatus": "",
"definitionName":"ClassTestVNext",
"projectId": "578ca584-4268-4ba2-b579-7aaee499c306"
},
"consumerInputs":{"url":"http://XXXX/"}
}
The problem I'm having is with this code:
if (!MessageQueue.Exists(QueueName))
{
MessageQueue.Create(QueueName, true);
}
It will check if a queue exists; if it doesn't I want it to create the queue. This code has been working and hasn't changed for a few months. Today I started receiving this error:
[MessageQueueException (0x80004005): A queue with the same path name
already exists.] System.Messaging.MessageQueue.Create(String path,
Boolean transactional) +239478
The queues are local and if I delete the specific queue it will work once. After the queue is created it starts to fail again with the same error message.
It looks like the issue may be because of the Network Load Balancing (NLB) configuration. I was unaware of a change that recently put the machine in a NLB environment. The configuration we are using is an unsupported one.
More information is in How Message Queuing can function over Network Load Balancing (NLB).
After I create an instance on OpenStack with the REST API Using the Nova endpoint the operation succeeds with the server id reference. If I immediately try to get any of the details of the network interfaces (using the /servers/server-id/ips) I get nothing, not even an error message that the resource is busy. If I put an arbitrary 30 second wait, I'll get the details. Is there any API call that can use on OpenStack to get a "is ready" state after a creation?
If there is no operation to determine that the server is ready, then is there a recommended wait time in the documentation?
You should wait for the instance to be in the "active" state. That's when the instance has been fully built, including network. You're probably hitting the instance while its still in the "building" state.