Checkpoint sync fails with "Attempt to download checkpoint state timed out" on holesky on all endpoints about nimbus-eth2 HOT 7 CLOSED

Closing because the issue per se is resolved, but that doesn't prevent further comments.

from nimbus-eth2.

Those curl command results are not successfully getting checkpoint states either, they're just requesting the main website front pages of those sites.

If you use the /eth/v2/debug/beacon/states/finalized REST endpoint shown by https://nimbus.guide/trusted-node-sync.html#sync-from-checkpoint-files directly via curl, what happens?

# Obtain a state and a block from a Beacon API - these must be in SSZ format:
curl -o state.finalized.ssz \
  -H 'Accept: application/octet-stream' \
  http://localhost:5052/eth/v2/debug/beacon/states/finalized

# Start the beacon node using the downloaded state as starting point
./run-mainnet-beacon-node.sh \
  --finalized-checkpoint-state=state.finalized.ssz

where localhost:5052 is one of the hosts from https://eth-clients.github.io/checkpoint-sync-endpoints/ instead

from nimbus-eth2.

Ty @tersec, the manual workaround worked flawlessly, stil unsure why the trusted-node-url fails on all official holesky endpoints allwhile the manual curl to the same exact EP works.

Downloading the state:

Beacon node started sucesfully and is syncing:

from nimbus-eth2.

curl required 1m7s to download the state, while the timeout for that request in Nimbus is 60s:

There's no strongly principled reason it must be exactly 60s, though. A machine which requires 10 minutes to download the state probably can't keep up with the ongoing Ethereum gossip anyway, but a more modest increase is reasonable. Created #6363 to increase this timeout to 90s, which would have sufficed here.

from nimbus-eth2.

Created #6363 to increase this timeout to 90s, which would have sufficed here.

Ty @tersec for the help!

IMHO, 120 would be a better, timeout, perhaps even 180? Network issues can occur even when you have a decent connection.

Question regarding this:

# Start the beacon node using the downloaded state as starting point
./run-mainnet-beacon-node.sh \
  --finalized-checkpoint-state=state.finalized.ssz

I'm assuming I can I drop the --finalized-checkpoint-state=state.finalized.ssz part on the next restart?

from nimbus-eth2.

Created #6363 to increase this timeout to 90s, which would have sufficed here.

Ty @tersec for the help!

IMHO, 120 would be a better, timeout, perhaps even 180? Network issues can occur even when you have a decent connection.

Question regarding this:

# Start the beacon node using the downloaded state as starting point
./run-mainnet-beacon-node.sh \
  --finalized-checkpoint-state=state.finalized.ssz

I'm assuming I can I drop the --finalized-checkpoint-state=state.finalized.ssz part on the next restart?

Well, 90s is at least longer, so merged that. It can be changed later. Especially as the mainnet and Holesky states grow larger over time ("state bloat" has been a long discussed issue in Ethereum), this might have to increase by default.

And, yes, you can drop --finalized-checkpoint-state=state.finalized.ssz next time.

from nimbus-eth2.

Ty @tersec for all your help!

from nimbus-eth2.