This repository has been archived by the owner on Nov 15, 2023. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 2.6k
grandpa: don't error if best block and finality target are inconsistent #13364
Merged
Merged
Changes from all commits
Commits
Show all changes
4 commits
Select commit
Hold shift + click to select a range
5758370
grandpa: don't error if best block and finality target are inconsistent
andresilva cc75f6b
grandpa: add test for best block override
andresilva 5763f08
grandpa: make clippy happy
andresilva 220f6ee
grandpa: log selectchain override as debug instead of warn
andresilva File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
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
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
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This entire check here is a little bit shit and that we then log some warning. This doesn't need to be an issue as between both of these calls there can be a reorg, leading to the case that the finality target isn't in the chain of the best block.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@andresilva what about applying the strategy you initially suggested? That is don't have to separate calls as to modify the
finality_target()
method to return a tuple(target, best)
in one shot?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@bkchr I don't know what you mean, or rather I don't understand what I should do with your comment. This can happen due to a race condition but it can also happen that
SelectChain
is returning inconsistent results (which I suspect is the root cause of the issue on Westend).@davxy I think that should still be the goal but wanted to get a quick fix PR to address the issue on Westend. After we change
SelectChain::finality_target
we might still want to be defensive against "bad" implementations and do this check anyway.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just wanted to say that there can be a race between getting the finality target and getting the best block. I mean it is totally legit that the best block for example goes backwards when the longest/best chain has a valid dispute. And in this case the finality target could also be greater than the "New best block"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Indeed, and that is the result of doing two distinct async calls where the underlying blockchain state may change. We can avoid that by making sure that we get all the data in a single call to
SelectChain::finality_target
(what @davxy talks about in his comment). But we still don't control what is returned bySelectChain
, and it probably still makes sense to have this check when we fix that and/or we need to make sure that the PolkadotSelectChain
respects this invariant (e.g. after #13289 we know that invariant holds forLongestChain
).There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can remove the logging (or downgrade to debug/trace) if you think it will cause confusion.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I downgraded the logging to
debug
. I think it's useful to log this as it can help us catch "bad"SelectChain
implementations, but it's useless for end users to be presented with this warning.