eth_chainId may return an error for unsynced eth1 nodes

[pawanjay176]

Description

Earlier, geth used to return chainId as 0 when it was not fully synced. With ethereum/go-ethereum#21686 , now it returns an error if it's not past the eip 155 block. Need to handle this error scenario.

Version

Lighthouse stable, Geth 1.10

Present Behaviour

We get an Endpoint NotReachable error on lighthouse when geth sync is not past the eip 155 block which is misleading.

Expected Behaviour

Should handle the error case and return Not Synced error message.

Steps to resolve

Handle the error case here

lighthouse/beacon_node/eth1/src/service.rs

Lines 162 to 164 in 9eb1945

	let chain_id = get_chain_id(endpoint, Duration::from_millis(STANDARD_TIMEOUT_MILLIS))
	.await
	.map_err(error_connecting)?;

[jmcph4]

@pawanjay176 Are you suggesting adding the "Not Synced" error condition to EndpointError here?

lighthouse/beacon_node/eth1/src/service.rs

Line 45 in 9eb1945

pub enum EndpointError {

[pawanjay176]

@jmcph4 the EndpointError::FarBehind implies that the eth1 node is not synced so we can use that instead.

I think the simplest way to resolve this would be to return a Eth1Id::Custom(0) on getting the error message from the eth1 node since we return a FarBehind endpoint on getting chainId of 0 anyway

lighthouse/beacon_node/eth1/src/service.rs

Lines 167 to 174 in 9eb1945

	if chain_id == Eth1Id::Custom(0) {
	warn!(
	log,
	"Remote eth1 node is not synced";
	"endpoint" => endpoint,
	"action" => "trying fallbacks"
	);
	return Err(EndpointError::FarBehind);

You will have to modify the get_chain_id function here to return a Eth1Id::Custom(0) on the specific eip 155 error

Let me know if you have other questions

[jmcph4]

@pawanjay176 Thanks for the clarification. I'm currently just playing around with the various RPC calls and seeing how both Geth behaves and how Lighthouse handles responses.

Do you think matching against the Geth error string in eth_chain_id is the way to go?

[pawanjay176]

Do you think matching against the Geth error string in eth_chain_id is the way to go?

Yep. This is the only case afaik where we need to parse an error from geth into something valid. If I remember correctly, Nethermind and OpenEthereum return the correct chain id right from when syncing starts, so this is a geth specific issue.

I can't think of a better way. @paulhauner any ideas?

[paulhauner]

Resolved in #2304