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.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix additional edge cases in fast sync process #5663
base: master
Are you sure you want to change the base?
Fix additional edge cases in fast sync process #5663
Changes from 2 commits
0ada692
f076138
99a052f
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
What if
peer.best_number > best_number
? The fix won't work and the duplicate block request will be issued?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.
Good point. The fix is incomplete in this case, the block requests would include both the duplicate and new blocks, so the gap sync will still be interrupted unexpectedly. I'll need some more time to think about it.
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'm running out of ideas on how to completely avoid duplicate block requests. The challenge lies in how duplicate block processing interferes with the gap sync state.
Why duplicate blocks pollute the gap sync state
Block request confusion: The main issue in the current chain sync is that multiple types of block requests are made, but the handler can't distinguish between them. As a result, blocks requested from one type of request can interfere with another sync component. For example, when duplicate blocks in the range [
finalized_number
,best_number
] are requested viapeer_block_request()
, once these blocks are received and enqueued,gap_sync.best_queued_number
is updated tobest_number
.polkadot-sdk/substrate/client/network/sync/src/strategy/chain_sync.rs
Lines 1295 to 1299 in 03f6e42
This causes a problem because no further blocks will be requested from
peer_gap_block_request()
asgap_sync.best_queued_number == peer.best_number
, leading to a failure in downloading the block history.Impact on
gap_sync_complete
detection: The detection of whether gap_sync is complete can be affected by importing duplicate blocks, as I explained in the second commit message.The second point can be updated to
let gap_sync_complete = self.gap_sync.is_some() && self.client.info().block_gap.is_none();
which is more reliable too. However, I still haven’t found a solution for the issue withgap_sync.best_queued_number
outlined in the first point.To ensure gap sync functions as expected, I suggest detecting whether a block response contains duplicate blocks in gap sync and preventing those duplicates from being processed further. This would prevent pollution of the gap sync state and allow block history to be downloaded correctly. Thoughts? @dmitry-markin