eth: when triggering a sync, check the head header TD, not block #20780
+4
−4
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR fixes a regression introduced in v1.9.0 by the freezer, unfortunately that regression was completely silent and was surfaced only by b9c90c5.
The symptom is when a miner is started against an empty database, instantly mines a block, and then fast syncs... crashing. Since the node mined a block, it's current head block is 1, with
hashA
. Fast sync will start and dump a whole lot of data into the freezer/ancient database (including block 1, withhashB
). Later on, any code that accesses thecurrentBlock
, will want data belonging tohashA
, but the freezer only has data belonging tohashB
.The crash is due to the sync code accessing the current block and then it's TD, which is returned as
nil
, since the hash doesn't match (the crash is due to b9c90c5 actually validating the hash, previously we trusted it blindly).The fix is to change the sync code to base it's TD retrieval on the head header, instead of the head block. This is actually the correct behavior as throughout fast sync the current block is the genesis, we've been doing it wrong for 4 years. This will also solve the panic because the head header is either the actual one from the ancient db, or if it's newer than the ancient limit then we'll always have it.
Fixes #20770, #20614