Proper Connection Management for ETH JSON-RPC Client for Startup and Runtime #10498
Conversation
| @@ -0,0 +1,166 @@ | |||
| package powchain | |||
There was a problem hiding this comment.
This file consolidates connection management functions and refactors for nicer separation of concerns
| ) | ||
|
|
||
| func (s *Service) setupExecutionClientConnections(ctx context.Context, currEndpoint network.Endpoint) error { | ||
| client, err := newRPCClientWithAuth(currEndpoint) |
There was a problem hiding this comment.
The initialization of an RPC client does not dial until we make an actual RPC call, so we then set the client as part of the service struct and avoid panics, as it will not be nil
rauljordan
added
Ready For Review
Priority: High
| @@ -15,7 +15,7 @@ var ( | |||
| HTTPWeb3ProviderFlag = &cli.StringFlag{ | |||
| Name: "http-web3provider", | |||
| Usage: "A mainchain web3 provider string http endpoint. Can contain auth header as well in the format --http-web3provider=\"https://goerli.infura.io/v3/xxxx,Basic xxx\" for project secret (base64 encoded) and --http-web3provider=\"https://goerli.infura.io/v3/xxxx,Bearer xxx\" for jwt use", | |||
| Value: "", | |||
| Value: "http://localhost:8545", | |||
There was a problem hiding this comment.
Any reason to change this ? it will break the case when we have a provided genesis state and want to sync the beacon node from scratch without an eth1 endpoint.
There was a problem hiding this comment.
Resolved offline: we discussed this will not break the case with the provided genesis state, and confirmed Prysm can still sync fine on mainnet to align with current behavior
…bs/prysm into robust-connection-management
What type of PR is this?
What does this PR do? Why is it needed?
With the merge around the corner, Prysm will need a connection to an execution client, even on startup. Currently, the connection to the execution client is something that happens in the background and is mostly used to retrieve deposit lgos from the Validator Deposit Contract. This needs to come front and center for the merge. However, we cannot afford to make a breaking change to current Prysm users until we ship Prysm v3.
Moreover, we need to make sure that whatever solution we pick, we do not crash nor shutdown Prysm. That is, Prysm should be able to continue even if the RPC connection goes down. If this occurs, we should just error where the calls are made to the execution client, and attempt a reconnection and proceed normally.
This PR is tested on both kiln and mainnet. On mainnet, the behavior remains the same as today. On Kiln, if the RPC connection is not found, the node can continue as normal, but will typically get stuck in a sync loop until the connection is restored. The node can fully sync after the connection is restored.
IMPORTANT CHANGES