This repository has been archived by the owner on Nov 15, 2023. It is now read-only.
Finalize target block after warp sync #2696
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
davxy
added
B0-silent
davxy
requested review from
bkchr,
andresilva,
koute,
michalkucharczyk,
skunert and
a team
skunert
reviewed
Jun 6, 2023
skunert
approved these changes
Jun 6, 2023
bkchr
approved these changes
Jun 6, 2023
Co-authored-by: Sebastian Kunert <[email protected]>
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
TL;DR
This PR addresses the following issues:
restoreprocedure after warp sync and if node is restarted during block-history downloadFixes: #2659
May help with: paritytech/substrate#13202
Depends on paritytech/substrate#14308
Warping without the fix
Finalized block number is not updated until we've not finished block history download.
This is a source of issues in case we stop and restart the node while we are downloading block history.
Issues:
restoreprocedure: we are trying to compute a route from last finalized (that is still 0) to each of the leaves. Because the blocks in the gap were not downloaded yet, this triggers a panic.The monitor will end up containing the full block history from gap start to the leaves.
At the end of the block-history download finalized flag is finally set to the proper value, thus the monitor is cleaned up.
We can do a lot better and mimic what the relay chain actually does (see "Warping with fix below").
Log before fix (statemine)
Warping with the fix
Once we discovered what is the last target block (according to the relay-chain) we should import this block as final (i.e. setting the
BlockImportParams::finalizedflag totrue).The adopted strategy mimics what
grandpaalready does here and thus here.That is, the finalized flag is set to true if the block also contains the state.
AFAIK in practice this is true only for the warp sync target block.
Log after the fix (statemine):
As can be seen the finalized block correctly starts being updated after state is imported, as expected.
Additional notes
Cumulus node caches the parachain blocks that are signaled as final here
and triggers a
Finalized::finalize_block()for each block found in the cache.This procedure marks the block as final BUT doesn't check if the block that we are finalizing is below the current "best" block.
As a consequence may happen that the finalized block number > best.
We don't want this as it also by-passes some general assumptions spread around the code.
To correctly handle cases like this a more defensive check been introduced in Substrate by paritytech/substrate#14308