-
Notifications
You must be signed in to change notification settings - Fork 745
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
Don't request block components until having block #5774
Conversation
.block_missing_components() // blobs not yet imported | ||
.blobs_response_was_valid() | ||
.blob_imported(); // now blobs resolve as imported | ||
} |
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.
Blobs can't be returned first
.expect_penalty("NoResponseReturned") | ||
.expect_block_request() | ||
.expect_no_blobs_request(); | ||
} |
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.
Scenario already covered by empty_block_is_retried
.expect_no_block_request() | ||
.expect_no_blobs_request() | ||
.block_response_triggering_process() | ||
.missing_components_from_block_request(); |
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.
Scenario already covered by empty_block_is_retried
.blobs_response() // blobs are not sent until the block is processed | ||
.expect_no_penalty_and_no_requests() | ||
.block_response_triggering_process(); | ||
} |
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.
Can't respond blobs first, same for too_many_blobs_response_then_block_response_attestation
@mergify queue |
✅ The pull request has been merged automaticallyThe pull request has been merged automatically at 683d9df |
Issue Addressed
Current stable when creating a new block lookup for
block_root
will:block_root
before knowing if the block has blobs and how manyThis optimistic / blind request forces us to handle the case where we have processed blobs + blocks and turns out that the blob peer did not return enough blobs.
By delaying fetching blobs until we get the block we can be sure to:
Proposed Changes
ActiveBlobsByRootRequest
to expect peer to return exactly the number of requested blobs. Else error withNotEnoughResponsesReturned
AvailabilityProcessingStatus::MissingComponents && both_components_processed == true
hard error as an internal error. The condition above should ensure that this never happenssingle_block_response_then_too_many_blobs_response_attestation
the sync network context can produce multiple return values for a single request. In the test case it produces: (1)Some(blobs)
, (2)Err(TooManyResponses)
. However block lookup mod expects a single result, so we track if the request has been resolved (= a result value has been returned). If resolved, downscore but do not forward the result