Open somnathb1 opened 3 months ago
that could be due to invalid blockbodies file for required range, remove them and restart just to see if case persists, you are just 30k blocks away from 0.
It will probably work, but the node should be able to auto-recover from this situation. Also, it can be expected of the node to not be stuck with a missing block body and download it from the network. There is a bug somewhere in the downloader
that could be due to invalid blockbodies file for required range, remove them and restart just to see if case persists, you are just 30k blocks away from 0.
System information
Erigon version:
./erigon --version
3.00.0-alpha1-da0d58c2OS & Version: Linux
Commit hash: git_commit=da0d58c2bf7271a53df8b96db9779feeca9fced1
Consensus Layer: Lighthouse
Consensus Layer Command (with flags/config):
Chain/Network: Pectra-devnet-2
Expected behaviour
Erigon unwinds to the point of the fork, downloads the correct blocks based on the hashes obtained from the CL
Actual behaviour
Erigon is stuck on
even if downloaded blocks around the stuck block height
Steps to reproduce the behaviour
Let an erigon client fork for some reason. Stop it, restart it after some time.
Backtrace
Attached devops grandine erigon.txt