-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
feat: allow awaiting payload in progress #11823
Conversation
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'd like to introduce an enum that represents the requested payload kind, this way could easier change this in the future and an enum is generally better for this than a bool arg
crates/payload/builder/src/traits.rs
Outdated
fn resolve( | ||
&mut self, | ||
wait_for_pending: bool, | ||
) -> (Self::ResolvePayloadFuture, KeepPayloadJobAlive); |
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'd prefer an enum instead of the bool that represents the targeted payload kind
Co-authored-by: Matthias Seitz <[email protected]>
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 more suggestions
crates/payload/primitives/src/lib.rs
Outdated
pub enum PayloadKind { | ||
/// Returns the best available payload, without waiting for pending job to finish. | ||
#[default] | ||
BestAvailable, |
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 isn't quite right, from CL pov we want a payload as fast as possible, so where this would be relevant is if there's no best payload yet we start racing the empty payload against the in progress payload:
reth/crates/payload/basic/src/lib.rs
Lines 545 to 546 in b77265e
/// If no payload has been built so far, it will either return an empty payload or the result of the | |
/// in progress build job, whatever finishes first. |
so this mode is more like Earliest
crates/payload/builder/src/traits.rs
Outdated
&mut self, | ||
wait_for_pending: bool, | ||
) -> (Self::ResolvePayloadFuture, KeepPayloadJobAlive); | ||
fn resolve(&mut self, kind: PayloadKind) -> (Self::ResolvePayloadFuture, KeepPayloadJobAlive); |
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 want to keep this non breaking because this is currently used by users.
we should instead introduce a new function that accepts the kind and resolve
calls this with Kind::Earliest
pub async fn resolve( | ||
&self, | ||
id: PayloadId, | ||
wait_for_pending: bool, | ||
kind: PayloadKind, | ||
) -> Option<Result<T::BuiltPayload, PayloadBuilderError>> { |
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.
same pattern here, basically just as:
reth/crates/net/network-api/src/lib.rs
Lines 131 to 138 in b77265e
/// Adds a peer to the known peer set, with the given kind. | |
fn add_peer_kind( | |
&self, | |
peer: PeerId, | |
kind: PeerKind, | |
tcp_addr: SocketAddr, | |
udp_addr: Option<SocketAddr>, | |
); |
reth/crates/net/network-api/src/lib.rs
Lines 121 to 124 in b77265e
/// Adds a trusted peer to the peer set with TCP `SocketAddr`. | |
fn add_trusted_peer(&self, peer: PeerId, tcp_addr: SocketAddr) { | |
self.add_peer_kind(peer, PeerKind::Trusted, tcp_addr, None); | |
} |
reth/crates/net/network-api/src/lib.rs
Lines 106 to 109 in b77265e
/// Adds a peer to the peer set with TCP `SocketAddr`. | |
fn add_peer(&self, peer: PeerId, tcp_addr: SocketAddr) { | |
self.add_peer_kind(peer, PeerKind::Static, tcp_addr, None); | |
} |
crates/payload/basic/src/lib.rs
Outdated
let fut = ResolveBestPayload { | ||
best_payload, | ||
maybe_better, | ||
empty_payload, | ||
wait_for_pending: kind == PayloadKind::WaitForPending, | ||
}; |
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.
here we don't need to pass the kind as argument instead we can control it based on whether we set the empty_payload
if Kind.is_earliest
then we can keep this as none so the ResolveBestPayload will only race the two real payloads against each other
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.
rn if payload job is still in progress ResolveBestPayload
would always return the best_payload
, so we need to somehow make it poll the pending one until completeion I think?
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.
imo this is fine, because you still want to return as fast as possible and if we already have one we should probably return that asap, the pending could even be the same or is not guaranteed to be better
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.
updated, though I think there's an edge case when pending job fails leaving us with nothing to return
but given this is only used in --dev mode for now I think it should be OK
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.
lgtm
d5e5d95
to
67ed467
Compare
Closes #11716
Added
wait_for_pending
argument toresolve
methods which allows to configure whether returned future should wait for a payload job in progress.Added
resolve
method and removed unusednew_payload
andsend_and_resolve_payload
methods fromPayloadBuilder
trait.