Skip to content
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.

Sign up for GitHub

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

Jump to bottom

bugfix: request fragment tree membership for all candidates #3874

Merged
merged 2 commits into from
Mar 28, 2024
Merged

bugfix: request fragment tree membership for all candidates #3874

Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
3aed2c4
backing: request fragment tree membership for all candidates
alindima Mar 28, 2024
e16066d
Merge branch 'master' into alindima/async-backing-bug
alindima Mar 28, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion polkadot/node/core/backing/src/lib.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -911,7 +911,7 @@ async fn handle_active_leaves_update<Context>(
}

let mut seconded_at_depth = HashMap::new();
if let Some(response) = membership_answers.next().await {
while let Some(response) = membership_answers.next().await {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch! Any consequences for the current production chains ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

AFAICT, the only consequence of this bug is that when getting a new leaf, this validator may already have a valid seconded candidate to propose for backing, but it will not use it. It will accept a new collation. Collator protocol does not guard against this because it ends up calling the backing subsystem for this info.

So the only potential impact is that we would accept more collations than neccessary. The DOS potential is quite low considering that the chance of the previous candidate remains valid at this leaf is quite low (because allowed_ancestry_len will be 2).

match response {
Err(oneshot::Canceled) => {
gum::warn!(
Expand Down
Loading