I am using the instructions on https://pkg.go.dev/golang.org/x/build/cmd/coordinator#section-readme
to locally run a coordinator and buildlet. I have tried both on Darwin and Linux, but the results are that coordinator displays an error message saying:bad build params
Summary of the buildlet error is: connection refused
I suspect the coordinator is the issue because the buildlet works fine locally when the coordinator is not needed.
https://localhost:8119 is not working either.
It seems to me this could be a potential issue that needs to be submitted. Are these instructions currently working for anyone?
Related
I have a node running two jobs - they communicate with an external adaptor and then send the value on-chain.
One job works fine, which already tells me that the node can write on-chain.
The other job, receives the request, talks with the external adaptor (I have verified this on the external adaptor server) and then doesn't submit anything on-chain.
There is no way to debug this through the Operator UI. This is what it shows:
What should I do? I am running the Chainlink develop version because the most up-to-date stable version as a critical bug.
In the Chainlink node version 1.8.0, there are "Error" and "Runs" tabs in your node UI in the browser, and these 2 tabs allow you to view what's wrong with your job run. You can find the latest chainlink docker image here.
The error messages under the "error" tab are shown below, and the info can reflect the error your job encountered in the run.
If there are no "error" and "run" tabs in the browser or there is nothing shown in the UI, you can also find error info in the log file housed by the server running the Chainlink node. The default path of the Chainlink node log file is /chainlink/chainlink_debug.log, so you can log into the server that running the node and check the log for debugging.
Hope it helps.
I recently installed Heroku Redis. Until then, the app worked just fine. I am using Bull for queuing and ioredis as the redis library. I had connection issues initially but I have resolved that as I no longer get the error. However, this new Error described shows up.
Please check these details below;
Package.json Start Script
"scripts": {
"start": "sh ./run.sh"
}
run.sh file
node ./app/services/queues/process.js &&
node server.js
From the logs on the heroku console, I see this.
Processing UPDATE_USER_BOOKING... Press [ctrl C] to Cancel
{"level":"info","message":"mongodb connected"}
1 is my log in the process script. This tells me that the consumer is running and ready to process any data it receives.
2 Tells me that mongo is connected. It can be found in my server.js(entry file).
My challenge is after those 2 lines, it then shows this;
Error R10 (Boot timeout) -> Web process failed to bind to $PORT within 60 seconds of launch
Stopping process with SIGKILL
Error waiting for process to terminate: No child processes
Process exited with status 22
State changed from starting to crashed
So, I don't know why this is happening even when I have the PORT sorted out already as described in their docs. See this for clarity:
app.listen(process.env.PORT || 4900, ()=>{})
Note: It was working before until I introduced the Redis bit just a day ago.
Could there be an issue with the way I am running both server and the Queue process in the package.json file? I have been reading answers similar to this, but they are usually focused on the PORT fix which is not my own issue as far as I know.
TroubleShooting : I removed the queue process from the start script and the issue was gone. I had this instead
"scripts": {
"start": "node server.js -p $PORT"
}
So it becomes clear that this line below;
node ./app/services/queues/process.js was the issue
Now, How then do I run this queue process script? I need it to run to listen to any subscription and then run the processor script. It works fine locally with the former start script.
Please Note: I am using Bull for the Queue. I followed this guide to implement it and it worked fine locally.
Bull Redis Implementation Nodejs Guide
I will appreciate any help on this as I am currently blocked on my development.
So I decided to go another way. I read up on how to run background jobs on heroku with Bull and I got a guide which I implemented. The idea is to utilize Node's concurrency API. For the guide a wrapper was used called throng to implement this.
I removed the process file and just wrapped my consumer script inside the start function and passed that to throng.
Link to heroku guide on enabling concurrency in your app
Result: I started getting EADDR in use Error which was because that app.listen() is being run twice..
Solution: I had to wrap the app.listen function inside a worker and pass it to throng and it worked fine.
Link to the solution to the EADDR in use Error
On my local Machine, I was able to push to the Queue and consume from it. After deploying to heroku, I am not getting any errors so far.
I have tested the update on heroku and it works fine too.
We've got Cypress Dashboard running for some of our tests. I'm looking to expand that into some new tests, and have been trying to run it locally to confirm it's working.
Everything in our current pipelines is working fine with Dashboard.
Running tests locally without the --record flag is working fine as well.
However when I'm trying to run locally with Dashboard, I'm getting the following error:
We encountered an unexpected error talking to our servers.
We will retry 0 more times in ...
The server's response was:
RequestError: Error: connect ECONNREFUSED 127.0.0.1:1234
It does this 3 times and then gives up. I've not got anything else running on port 1234, and it runs absolutely fine on my colleagues machine.
The command I'm running is:
npx cypress run --record --key {record-key}
I've been through the Cypress docs for setting up Dashboard access, and besides setting up the project in Dashboard, and setting the Record Key and Project ID, there's no other setup I can see that's needed to get it running.
Only thing I've noticed is it very consistently is trying to hit :1234, but I'm not sure if that's notable at all. Has anyone got suggestions for stuff I may have setup on my local machine that might be blocking this?
I've also checked my HOSTS file, not seen anything obvious in there. Don't think I've actually made any amendments myself in there either, seems like Kubernetes has just added an address. Any suggestions of things I can look at or try would be greatly appreciated.
Try running cypress cache clear
I am running some cypress (version 9.5.2) tests on a project and when I execute it on my computer there is no problem. Everything is alright
But when I run it on my gitlab runner with docker as executor, I got some errors that I don't understand.
For example I got this one:
During a cy.wait(30000); at the middle I got this error
CypressError: Timed out after waiting 60000ms for your remote page
to load. Your page did not fire its load event within 60000ms. You
can try increasing the pageLoadTimeout value in cypress.json to
wait longer. Browsers will not fire the load event until all
stylesheets and scripts are done downloading.
So I don't understand to what this error is related, have you an idea ? I can share a video if you got any idea
I'm currently trying to deploy Eremetic (version 0.28.0) on top of Marathon using the configuration provided as an example. I actually have been able to deploy it once, but suddenly, after trying to redeploy it, the framework stays inactive.
By inspecting the logs I noticed a constant attempt to connect to some service that apparently never succeeds because of some authentication problem.
2017/08/14 12:30:45 Connected to [REDACTED_MESOS_MASTER_ADDRESS]
2017/08/14 12:30:45 Authentication failed: EOF
It looks like the service returning an error is ZooKeeper and more precisely it looks like the error can be traced back to this line in the Go ZooKeeper library. ZooKeeper however seems to work: I've tried to query it directly with zkCli and to run a small Spark job (where the Mesos master is given with zk:// URL) and everything seems to work.
Unfortunately I'm not able to diagnose the problem further, what could it be?
It turned out to be a configuration problem. The master URL was simply wrong and this is how the error was reported.