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
| _ = 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
3 times, most recently
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
julio4
force-pushed
the
feat/continuous-flashblock-build
branch
3 times, most recently
from
940ea59 to
b1e6208
Compare
julio4
force-pushed
the
feat/continuous-flashblock-build
branch
from
b1e6208 to
83fd70d
Compare
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.