-
Notifications
You must be signed in to change notification settings - Fork 1.6k
relay chain selection
and dispute-coordinator
fixes and improvements
#4752
relay chain selection
and dispute-coordinator
fixes and improvements
#4752
Conversation
Signed-off-by: Andrei Sandu <andrei-mihail@parity.io>
Signed-off-by: Andrei Sandu <andrei-mihail@parity.io>
Make sure to send errors to subsystems requesting data depending on missing session info Signed-off-by: Andrei Sandu <andrei-mihail@parity.io>
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.
A few nits, one conceptual question, the general approach looks good 👍
Signed-off-by: Andrei Sandu <andrei-mihail@parity.io>
Signed-off-by: Andrei Sandu <andrei-mihail@parity.io>
Signed-off-by: Andrei Sandu <andrei-mihail@parity.io>
Signed-off-by: Andrei Sandu <andrei-mihail@parity.io>
Signed-off-by: Andrei Sandu <andrei-mihail@parity.io>
Signed-off-by: Andrei Sandu <andrei-mihail@parity.io>
Signed-off-by: Andrei Sandu <andrei-mihail@parity.io>
Signed-off-by: Andrei Sandu <andrei-mihail@parity.io>
@@ -54,7 +54,7 @@ use std::sync::Arc; | |||
/// | |||
/// This is a safety net that should be removed at some point in the future. | |||
// Until it's not, make sure to also update `MAX_HEADS_LOOK_BACK` in `approval-voting` | |||
// when changing its value. | |||
// and `MAX_BATCH_SCRAPE_ANCESTORS` in `dispute-coordinator` when changing its value. |
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.
nit: We should probably add these shared constants to a separate helper crate, and import it, to avoid these manual keep in sync-todos
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.
Agreed, do you have any suggestion on what would be the best place to move this ?
AFAIK we also want to remove this in the near future, so if we were to create a new separate crate just to hold these constants, it won't be a good investment.
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.
Removed this, we now scrape up to and including last finalized 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.
I think it's out of s ope for this PR, but a tracking issue would be nice
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.
The reason we have though lookup limits is to avoid a very busy (and wasteful) loop on startup if the node is syncing and is very much behind the tip of the chain. Imagine if we get the first leaf, but not finality notification. The difference between the could be millions of blocks in theory. However, I'm not sure how much of a problem it's in practice.
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 meant the const extraction, not the issue you described, sorry about the brevity
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.
Looks good other than one concern: #4752 (comment).
Addressed it. We'll look back up to max(last_finalized_block_number, new_leaf -MAX_BATCH_SCRAPE_ANCESTORS);
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 meant the const extraction, not the issue you described, sorry about the brevity
#4788 is here
Signed-off-by: Andrei Sandu <andrei-mihail@parity.io>
Signed-off-by: Andrei Sandu <andrei-mihail@parity.io>
Signed-off-by: Andrei Sandu <andrei-mihail@parity.io>
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.
Looks good other than one concern: #4752 (comment).
max finality lag Signed-off-by: Andrei Sandu <andrei-mihail@parity.io>
Signed-off-by: Andrei Sandu <andrei-mihail@parity.io>
// Limit our search to last finalized block, or up to max finality lag. | ||
let block_number = std::cmp::max( | ||
block_number, | ||
new_leaf.number.saturating_sub(MAX_BATCH_SCRAPE_ANCESTORS), |
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.
👍
bot merge |
Please create a ticket for those. |
|
* master: Fix incomplete sorting. (#4795) Companion for better way to resolve `Phase::Emergency` via governance #10663 (#4757) Refactor and fix usage of `get_session_index()` and `get_session_info_by_index()` (#4735) `relay chain selection` and `dispute-coordinator` fixes and improvements (#4752) Fix tests (#4787) log concluded disputes (#4785) availability-distribution: look for leaf ancestors within the same session (#4596) Companion for Use proper bounded vector type for nominations #10601 (#4709) Fix release profile (#4778) [ci] remove publish-s3-release (#4779) Companion for substrate#10632 (#4689) [ci] pipeline chores (#4775) New changelog scripts (#4491)
Fixes #4748
Work in progress.
Fixes:
finality_target_with_longest_chain()
approval-voting
for processing active leaves such that even if we fail to process a block, we will eventually process it through a descendant.The below items will be taken care of in a subsequent PR.
Import improvements(always import trusted votes):