-
Notifications
You must be signed in to change notification settings - Fork 30
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(x/evmengine): process current block events during finalizeblock after forkchoice updated #328
base: main
Are you sure you want to change the base?
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.
LGTM
// require.Len(t, executionPayload.PrevPayloadEvents, 1) | ||
// evmLog := executionPayload.PrevPayloadEvents[0] | ||
// require.Equal(t, evmLog.Address, zeroAddr.Bytes()) |
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.
Are they not needed anymore?
if err := s.ProcessUbiEvents(ctx, payload.Number-1, msg.PrevPayloadEvents); err != nil { | ||
return nil, errors.Wrap(err, "deliver ubi-related event logs") | ||
|
||
if err := s.deliverEvents(ctx, payload.Number, events); err != nil { |
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.
If we change from processing payload.Number instead of payload.Number - 1 (i assume it is block height), will there be one block of data missing during upgrade?
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.
Yes, the linked issue specifies:
Note that on the network upgrade height itself, we should process both legacy previous block events as well as current block events. Otherwise we will miss events for upgrade height-1.
}, | ||
//{ |
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 assume these commented out tests will be reenabled in the future PRs?
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
@@ -20,7 +20,6 @@ message MsgExecutionPayload { | |||
option (cosmos.msg.v1.signer) = "authority"; | |||
string authority = 1; | |||
bytes execution_payload = 2; | |||
repeated EVMEvent prev_payload_events = 3; |
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 field should be reserved.
addresses omni-network/omni/issues/2106; event ordering is deterministic on the same payload received via p2p.
issue: none