Grandine does not retry Web3signer connection

[yorickdowne]

If Web3signer is not yet up when Grandine starts, Grandine will not retry the connection periodically, meaning it will not serve validator duties.

debian@eth-testing-ovh:~/eth-docker$ ./ethd logs consensus | grep -i Web3signer
consensus-1  | [2024-03-13T11:47:16.563+00:00] [] [grandine::grandine_config] using Web3Signer API to sign validator messages (API URLs: [http://web3signer:9000/])
consensus-1  | [2024-03-13T11:47:16.592+00:00] [] [signer::web3signer::api] failed to load Web3Signer keys from http://web3signer:9000/: error sending request for url (http://web3signer:9000/api/v1/eth2/publicKeys): error trying to connect: dns error: failed to lookup address information: Name or service not known

[sauliusgrigaitis]

Thanks, our web3signer is always up so we didn't notice it :)

[sauliusgrigaitis]

@yorickdowne is there any sense to fetch again the keys from Web3Signer after it's loaded successfully first time? Seems there is no sense because the keys should be managed via Keymanager API only after the first load.

[yorickdowne]

This highly depends on how the VC gets deployed. In Eth Docker keymanager is used.

But I’ve seen different ways of deploying as well, where Web3signer gets new (or different) keys handed to it in the file system and then its reload endpoint is called, followed by telling the VC to check keys again. I believe Teku does this with a SIGHUP to the VC.

You may want to talk to the Teku team to see what design decisions they made.

In a nutshell, Key Manager API is one way of handling keys, not the only way. Eth Docker however has chosen to exclusively use the key manager API.

[sauliusgrigaitis]

So since 0.4.0.rc4 Grandine retries (once per epoch) to fetch keys from Web3Signer until the first successful attempt.