-
Notifications
You must be signed in to change notification settings - Fork 746
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
Stricter match of BlockError in lookup sync #6321
base: unstable
Are you sure you want to change the base?
Conversation
for peer in peer_group.of_index(index) { | ||
cx.report_peer( | ||
*peer, | ||
PeerAction::MidToleranceError, |
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 we should up this to LowToleranceError
); | ||
let recoverable = match other.rpc_scoring() { | ||
ErrorCategory::Internal { recoverable } => { | ||
if matches!(other, BlockError::ExecutionPayloadError(_)) { |
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 kept this extra condition from the original match as I imagine that when EL goes offline the node would spam non-actionable errors
a2ffbd2
to
5a69a7b
Compare
beacon_node/network/src/network_beacon_processor/sync_methods.rs
Outdated
Show resolved
Hide resolved
beacon_node/beacon_chain/src/data_availability_checker/error.rs
Outdated
Show resolved
Hide resolved
beacon_node/beacon_chain/src/data_availability_checker/error.rs
Outdated
Show resolved
Hide resolved
beacon_node/beacon_chain/src/data_availability_checker/error.rs
Outdated
Show resolved
Hide resolved
5a69a7b
to
33d10e5
Compare
@pawanjay176 I have moved the big match into the network beacon processor. This is analogous to how we handle the result of processing chain segments and gossip objects. I have applied all your comments to the current version. I think the PR makes much more sense now, ready for a re-review |
"Error processing block component"; | ||
"block_root" => %block_root, | ||
"err" => ?err, | ||
); |
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.
Do we want to log internal errors at a higher level than debug? If yes I can move the log statement below and match the type of ErrorCategory
Issue Addressed
Adds a strict match without fallbacks to handle all processing errors in lookup sync explicitly. With this we can:
Example problem 1
Today, if a block has incorrect state root we will download and process it 5 times. This is wasteful, we should discard the block immediately
Example problem 2
Assume we introduce a new
BlockError
variant in a future fork or network change. Lookup sync is very sensitive code, and not handling this error variant properly may result in sync getting stuckProposed Changes
In the network processor convert
BlockError
toLookupSyncProcessingResult
.Then lookup sync logic is quite simple match on
LookupSyncProcessingResult
, without fallbacks.