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.

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

Add individual by_range sync requests #6497

Open
wants to merge 2 commits into
base: unstable
Choose a base branch
from

Conversation

dapplion
Copy link
Collaborator

Issue Addressed

Part of

To address PeerDAS sync issues we need to make individual by_range requests within a batch retriable. We should adopt the same pattern for lookup sync where each request (block/blobs/columns) is tracked individually within a "meta" request that group them all and handles retry logic.

Proposed Changes

second step is to add individual request accumulators for blocks_by_range, blobs_by_range, and data_columns_by_range. This will allow each request to progress independently and be retried separately.

Most of the logic is just piping, excuse the large diff. This PR does not change the logic of how requests are handled or retried. This will be done in a future PR changing the logic of RangeBlockComponentsRequest.

Before

  • Sync manager receives block with SyncRequestId::RangeBlockAndBlobs
  • Insert block into SyncNetworkContext::range_block_components_requests
  • (If received stream terminators of all requests)
    • Return Vec<RpcBlock>, and insert into range_sync

Now

  • Sync manager receives block with SyncRequestId::RangeBlockAndBlobs
  • Insert block into SyncNetworkContext:: blocks_by_range_requests
  • (If received stream terminator of this request)
    • Return Vec<SignedBlock>, and insert into SyncNetworkContext::components_by_range_requests
    • (If received a result for all requests)
      • Return Vec<RpcBlock>, and insert into range_sync

@dapplion dapplion added ready-for-review The code is ready for review syncing labels Oct 16, 2024
// practice
//
// rig.expect_chain_segment();
// rig.expect_chain_segment();
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I want to migrate the range sync tests to the event-driven format but would prefer to do so in a separate PR

Copy link
Member

@realbigsean realbigsean left a comment

Choose a reason for hiding this comment

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

Looks really good overall!

@@ -43,12 +47,50 @@ pub struct DataColumnsByRootRequestId {
pub requester: DataColumnsByRootRequester,
}

#[derive(Debug, Hash, PartialEq, Eq, Clone, Copy)]
pub struct BlocksByRangeRequestId {
pub id: Id,
Copy link
Member

Choose a reason for hiding this comment

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

i'm understanding this is the sub-request id and requester.id is the meta-request id, can we rename one of them? it's sort of confusing

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

What name(s) do you have in mind? I can add docs otherwise

{
return Err(LookupVerifyError::UnrequestedSlot(item.slot()));
}
// TODO: Should check if index is within bounds
Copy link
Member

Choose a reason for hiding this comment

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

As in the blob index? might as well throw that check in now right

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Addressed in 5fa2912

@@ -211,21 +208,9 @@ pub struct SyncNetworkContext<T: BeaconChainTypes> {

/// Small enumeration to make dealing with block and blob requests easier.
pub enum BlockOrBlob<E: EthSpec> {
Copy link
Member

Choose a reason for hiding this comment

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

Might be time to rename this.. maybe RangeBlockComponent because it should be the wrapper for the return type of RangeBlockComponentRequest?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Addressed in 5fa2912

"epoch" => epoch,
"peer" => %peer_id,
);
let _blocks_req_id = self.send_blocks_by_range_request(peer_id, request.clone(), id)?;
Copy link
Member

Choose a reason for hiding this comment

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

The _blocks_req_id here is unused and blobs_req_id is only used to check if a blobs request was made. I don't see these send_ methods used anywhere else so I think we can return Result<(), ..> rather than Result<BlocksByRangeRequestId, ..> for blocks. Maybe a bool for blobs. Looks like for custody columns, we care about the count requested but not particular ids

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

In a future PR RangeBlockComponentsRequest will track individual requests by ID. Left this variable named but unused as a hint that it should be used.

None
}
}

/// Received a blocks by range or blobs by range response for a request that couples blocks '
/// and blobs.
pub fn range_block_and_blob_response(
Copy link
Member

Choose a reason for hiding this comment

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

another rename suggestion range_block_component_response

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Addressed in 5fa2912

if let Err(e) = {
let request = entry.get_mut();
match block_or_blob {
BlockOrBlob::Block(resp) => match resp {
Copy link
Member

Choose a reason for hiding this comment

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

Can do this here and for blobs and columns as well

resp.map(|(blocks, _)| {
    request.add_blocks(blocks);
})

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Addressed in 5fa2912

Base automatically changed from sync-active-request-generalize to unstable October 17, 2024 18:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ready-for-review The code is ready for review syncing
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants