-
Notifications
You must be signed in to change notification settings - Fork 24
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Failing to make async request to nodes #671
Comments
The Etna DevNet has been torn down now that testing of the Etna upgrade has been completed and the upgrade activated on both Fuji and Mainnet. This repository is archived for reference, but commands and tutorials in it are no longer maintained and will likely not work. For up-to-date documentation and tutorials on how to launch Avalanche L1s, see https://docs.avax.network/. |
I recommend this tutorial for creating an Avalanche L1 on Fuji Testnet using the CLI: https://build.avax.network/docs/tooling/create-deploy-avalanche-l1s/deploy-on-fuji-testnet. |
Hey @meaghanfitzgerald ! Thanks for the response - the primary error/logs I provided were related to a function Specifically, I'm calling this in the avalanche-cli
|
Hey @tedim52, I believe @containerman17 and @owenwahlgren might be able to help understand why you're catching this error. |
One of the most common reasons for the signature aggregator to not be able to reach your L1 nodes is if they don't correctly NAT traverse to automatically determine their IP. Try restarting your validator nodes with |
Hey! Thanks for the response @iansuvak - so I am running a local avalanche node network inside a docker subnetwork. The signature aggregator code is running in a service in that same docker subnetwork. When setting the |
Hey @tedim52 . So it sounds like you are using cli to do to the conversion. If you try the latest rc version of the CLI it might work. The problem is that the way that signature aggregator discovers how to reach each node depends on peer gossip on the primary network and it does so on demand at the time that the first request to it happens. So it is expected for the first request to take longer and subsequent ones for the same subnet/L1 to be quicker. The newest RC tag of the CLI adds a wait step to wait for the network to report as healthy and connected to the subnet before attempting to aggregate signatures. Please give this a try and report back if it doesn't work. We are likely going to add a config workaround to allow for explicit manual tracking of IPs associated with NodeIDs intended for these private subnetwork usecases. |
Hey - so it turns out the issue was because the
|
Describe the bug
I'm trying to create a local etna devnet. I've following the steps here to do so:
https://github.com/ava-labs/etna-devnet-resources/tree/main
All the previous steps are working:
The only thing thats failing right now is the last step to initialize the validator set. I'm following exactly the code here:
https://github.com/ava-labs/etna-devnet-resources/blob/eba4c775127b66a466ba7429ff46ee8613bb9aa1/manual_etna_evm/cmd/01_12_initialize_validator_set.go#L60
To Reproduce
The part that is failing is the signatureAggregator.Sign(subnetConversionUnsignedMessage, subnetId[:]). I've attached logs below. It seems like the aggregator is failing to make requests to the node. I am running ava go node avaplatform/avalanchego:v1.12.0-fuji
Expected behavior
The signature aggregator is able to communicate with nodes and receive signatures.
Logs
Operating System
arm64
The text was updated successfully, but these errors were encountered: