-
Notifications
You must be signed in to change notification settings - Fork 3.4k
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
op-node: cl-sync using events #10903
Conversation
9061abb
to
a51ac9c
Compare
a51ac9c
to
402f4be
Compare
Semgrep found 1 Named return arguments to functions must be appended with an underscore ( Semgrep found 1 Malformed revert statement style. Ignore this finding from sol-style-malformed-revert.Semgrep found 1 Inputs to functions must be prepended with an underscore ( |
Todo: upon the temporary-error event we may want to request a forkchoice-update, so the CL-sync doesn't get stuck until the next payload/forkchoice update, to perform the retry of a temporarily failed payload. |
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. Just probably should leave TestSystemMockP2P
skipped if we haven't actually fixed the cause of its flakiness. Definitely good to have identified and run it manually though to confirm these changes.
Description
This is a step closer to making each driver-component communicate with events, and not attach synchronously to the engine-controller.
The CL-sync now monitors forkchoice updates and invalid-payload reports to maintain what payload should be suggested to the execution engine next.
It no longer directly interfaces with the engine-controller state.
The CL-sync checks are also robust enough to just drop payloads if the forkchoice moves past these at a later point. I.e. the node does not get stuck when a forkchoice-update event is missed.
Temporary errors are assumed to not bubble back any useful events, and instead the CL-sync waits for the next forkchoice-update to re-attempt.
TODO: should we poke it more explicitly after a temporary error, to not rely on new incoming blocks for the retry attempt?
Going to draft stacked PR on top of this first, the engine-controller really needs some simplification/improvement/testing.
To handle the "dead" moment when there's a new payload, but no forkchoice-updates to trigger processing, the CL-sync can request from the engine to communicate the latest forkchoice. That way no state is shared, and the CL-sync can continue processing.
Note: the engine-controller is enhanced with event-emits of forkchoice changes and payload-insertion (in the full payload case, not when building a payload from block-attributes).
Side-note: also moved the syncronous-events-emitter from
driver
intorollup
package, but did not end up needing it for cl-sync unit-testing. Added a mock-emitter instead, to catch/check emitted events.Tests
Metadata
Fix #10853