-
Notifications
You must be signed in to change notification settings - Fork 741
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
Remove generic E from RequestId #6462
Conversation
96ef419
to
a1f7761
Compare
a1f7761
to
0e7086f
Compare
@@ -323,11 +314,14 @@ pub struct BlobsByRangeRequest { | |||
|
|||
/// The number of slots from the start slot. | |||
pub count: u64, | |||
|
|||
/// maximum number of blobs in a single block. | |||
pub max_blobs_per_block: usize, |
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.
This value is the same on all requests, does it need to be appended to every request? Or can it be part of the handler struct
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.
Hi Lion, good question, the thing is:
lighthouse/beacon_node/network/src/sync/network_context.rs
Lines 406 to 415 in 48dd3f3
self.network_send | |
.send(NetworkMessage::SendRequest { | |
peer_id, | |
request: RequestType::BlobsByRange(BlobsByRangeRequest { | |
start_slot: *request.start_slot(), | |
count: *request.count(), | |
}), | |
request_id: AppRequestId::Sync(SyncRequestId::RangeBlockAndBlobs { id }), | |
}) | |
.map_err(|_| RpcRequestSendError::NetworkSendError)?; |
the request is created here for example, it's outside of the
Rpc
NetworkBehaviour
.Also
BlobsByRangeRequest::max_blobs_requested(&self)
requires it, how would you envision storing max_blobs_per_block
?My objective is for
Rpc
to be completely unaware of E: EthSpec
so that we can uncouple it from the rest of lighthouse and all its config values are passed dynamically.
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.
Actually, I take that back, if we increase the blob count we will have different requests with different limits at runtime. So okay with me to keep it on the 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.
I don't think we should have added this field to BlobsByRangeRequest
. It breaks the SSZ representation.
@Mergifyio queue |
✅ The pull request has been merged automaticallyThe pull request has been merged automatically at 772929f |
This reverts commit 772929f.
Issue Addressed
Continue cleaning up rpc code by removing unrequired generic
E
from request id, and passingMAX_BLOBS_PER_BLOCK
when constructing aBlobsByRange
request