feat: continuous-build mode#458
Conversation
julio4
requested review from
0x416e746f6e,
SozinM,
avalonche and
karim-agha
as code owners
julio4
force-pushed
the
reapply-async-payload-builder
branch
from
d83dffd to
cbe4b7a
Compare
julio4
force-pushed
the
feat/continuous-flashblock-build
branch
from
895a4a2 to
d45b137
Compare
julio4
force-pushed
the
feat/continuous-flashblock-build
branch
from
d45b137 to
3435df5
Compare
|
did you push your changes correctly? don't see code changes for comments |
julio4
force-pushed
the
feat/continuous-flashblock-build
branch
2 times, most recently
from
932b00a to
88c1026
Compare
julio4
force-pushed
the
feat/continuous-flashblock-build
branch
5 times, most recently
from
9fc7ebc to
8a3b18e
Compare
| store_shared_best(shared_best, candidate.clone()); | ||
| best = Some(candidate); |
There was a problem hiding this comment.
There was a problem hiding this comment.
Hum I see why it can seems slightly confusing but shared_best is the cross-thread channel so that the main building loop (outside of the continuous loop task, similar to the best_payload channel) always have access to "latest best candidate" without having to race anything on what continuous loop is doing. Because of that shared_best can be taken at any time hence why it's cloned here, and best is the local build state.
There was a problem hiding this comment.
Has there been a gap between cancelling the candidate loop and it actually ending? I wonder how necessary it is to do this. It would be simpler if the candidate loop just returned the best candidate
There was a problem hiding this comment.
Also, have you looked into using a tokio watch channel to track the best candidate? It seems like a natural fit to this problem
There was a problem hiding this comment.
watch channel is not the best fit here as there's a single consumer once and take ownership of the result, the channel adds a lot of useless mechanisms.
| _ = deps.payload_cancel.cancelled() => { | ||
| Self::record_cancellation_reason(self.metrics(), deps.payload_cancel, deps.span); | ||
| self.record_flashblocks_metrics( | ||
| &interval.base_ctx, | ||
| &interval.base_fb_state, | ||
| &interval.base_info, | ||
| target_flashblocks, | ||
| deps.span, | ||
| ); | ||
| return Ok(()); | ||
| } |
There was a problem hiding this comment.
payload_cancel is triggered when we receive the getPayload call, right? I figured we could publish the last flashblock then as well but here you're just exiting the loop. Is it not possible to do that? We would end up solving the race with ending block building and sending the last flashblock if possible
There was a problem hiding this comment.
payload_cancel is triggered when one of these fire: getPayload received, payload deadline reached, new FCU received.
I assumed that last trigger should always arrive before getPayload, but I agree with you this would be a nice improvement to submit last flashblock here if it's not the case.
There was a problem hiding this comment.
definitely, i think leveraging PayloadJobCancellation would be a good idea
There was a problem hiding this comment.
Yes but let's do this as a follow up
julio4
force-pushed
the
feat/continuous-flashblock-build
branch
2 times, most recently
from
9c53758 to
64fa2f5
Compare
julio4
force-pushed
the
feat/continuous-flashblock-build
branch
from
64fa2f5 to
e5e6711
Compare
| pub(super) base_ctx: OpPayloadJobCtx, | ||
| pub(super) base_fb_state: FlashblocksState, | ||
| pub(super) base_info: ExecutionInfo, |
There was a problem hiding this comment.
are these fields just used for metrics? if so can you find a better way of recording those metrics instead of carrying these clones around? It's not clear otherwise why you would need to duplicate this info from BuildState
3 participants
📝 Summary
Adds a continuous flashblock building mode (under
--flashblocks.continuous-buildflag) that pre-seals candidates between scheduler triggers, so the best block is ready for instant publish when the timer fires.