Make kurtosis runs faster when lighthouse is not first participant #7414
Description
We are using /eth/v1/node/health endpoint to check if a node is available.
When we run two lighthouse nodes:
participants:
- cl_type: lighthouse
- cl_type: lighthouseThere are no issues.
When lighthouse is not the first participant like the example below:
quick way to replicate:
participants:
- cl_type: teku
- cl_type: lighthouseI'm getting:
curl -v http://127.0.0.1:33008/eth/v1/node/health
* Uses proxy env variable no_proxy == '*'
* Trying 127.0.0.1:33008...
* Connected to 127.0.0.1 (127.0.0.1) port 33008
> GET /eth/v1/node/health HTTP/1.1
> Host: 127.0.0.1:33008
> User-Agent: curl/8.7.1
> Accept: */*
>
* Request completely sent off
< HTTP/1.1 503 Service Unavailable
< content-type: application/json
< server: Lighthouse/v7.0.1-e42406d/aarch64-linux
< content-length: 113
< date: Wed, 07 May 2025 15:57:07 GMT
<
* Connection #0 to host 127.0.0.1 left intact
{"code":503,"message":"SERVICE_UNAVAILABLE: beacon node is syncing: execution layer is offline","stacktraces":[]}This bug seems to happen regardless the EL used or the but dependent on which CL is used.
Issues when the first participant is:
teku , grandine,
No issues when first participant is:
prysm , lodestar, nimbus
LH also reports:
May 07 16:03:16.811 ERRO Error updating deposit contract cache error: Failed to update deposit cache: GetDepositLogsFailed("eth_getLogs call failed ServerMessage { code: -32000, message: \"invalid block range params\" }"), retry_millis: 60000, service: deposit_contract_rpc
...
May 07 15:58:41.599 WARN Error processing HTTP API request method: GET, path: /eth/v1/node/health, status: 503 Service Unavailable, elapsed: 1.255048msThis bug slows down the startup process of each enclave by ~30s