refactor: extract post-seal side-effects into PostSealHook trait#518
refactor: extract post-seal side-effects into PostSealHook trait#518julio4 wants to merge 2 commits into
Conversation
|
I do want a hook system, but it's not clear to me this is the right design for it. For the time being it would be better to not have the new trait and context types, and instead extract the side-effects a different way where each one only has the minimal amount of information for it to run. |
julio4
force-pushed
the
refactor/extract-post-seal-hooks
branch
from
d945cae to
7edeb12
Compare
Hm yes I agree that the ctx is encapsulating too much here. I tried to rework this by adding a more immutable Slot Metadata and derive more information directly from the payload built itself. |
Move WS publication, p2p forwarding, engine propagation, and per-flashblock metrics out of the building loop and behind a PostSealHook trait. Hooks are constructed once in OpPayloadBuilder::new() and dispatched after each sealed candidate (fallback + every flashblock). build_next_flashblock no longer performs side-effects: it returns a FlashblockBuildResult struct and the async loop handles dispatch. The side-effect call sites in the fallback path and the FB iteration are collapsed to a single dispatch_post_seal call each. p2p and engine forwarders are unified as ChannelHook(name, sender) since they only differ in the failure log label.
julio4
force-pushed
the
refactor/extract-post-seal-hooks
branch
from
7edeb12 to
849ba74
Compare
3 participants
Move ws publication, p2p forwarding, engine propagation, and per-flashblock metrics out of the building loop behind a
PostSealHooktrait. Hooks are constructed once and dispatched after each sealed candidate (fallback + every flashblock).build_next_flashblockno longer performs side-effects: it returnsFlashblockBuildResultstruct and the async loop handles dispatch.