-
Notifications
You must be signed in to change notification settings - Fork 2.6k
Fixed sync skipping some block announcements #8459
Conversation
@@ -507,7 +507,7 @@ impl<B: BlockT> ChainSync<B> { | |||
|
|||
/// Number of active sync requests. | |||
pub fn num_sync_requests(&self) -> usize { | |||
self.fork_targets.len() | |||
self.fork_targets.values().filter(|f| f.number <= self.best_queued_number).count() |
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.
Why do we need to filter here?
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 function is used in tests to detect when there's no activity (block_unti_idle
). Since now fork_targets
might contain some future blocks, that are not requested until we reach that block number it will stall tests. Basically only forks that can be requested are considered as active.
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.
Ahh okay, ty. Maybe we should add some comment to the function to explain this :D
hash, | ||
announce.summary(), | ||
); | ||
self.fork_targets |
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.
So, the problem was that we only synced forks if the block number was below our best number?
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.
If the block was below best, sync assumed it will be downloaded by simply advancing from peers common number. fork_targets
was intended for old forks that are behind our current best block, but it is clear now this mechanism should be used for parallel current forks as well.
No issues revealed in burn-in |
Co-authored-by: André Silva <123550+andresilva@users.noreply.github.com>
* Fixed sync missing some block announcements * Apply suggestions from code review Co-authored-by: André Silva <123550+andresilva@users.noreply.github.com> Co-authored-by: André Silva <123550+andresilva@users.noreply.github.com>
* Fixed sync missing some block announcements * Apply suggestions from code review Co-authored-by: André Silva <123550+andresilva@users.noreply.github.com> Co-authored-by: André Silva <123550+andresilva@users.noreply.github.com>
* Fixed sync missing some block announcements * Apply suggestions from code review Co-authored-by: André Silva <123550+andresilva@users.noreply.github.com> Co-authored-by: André Silva <123550+andresilva@users.noreply.github.com>
In rare cases a block announcement would be ignored if a peers that sends has an outstanding block request. This PR fixes this by adding all announcement to fork targets.