-
Notifications
You must be signed in to change notification settings - Fork 105
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(evm)!: prioritize executing burn commands #1268
Conversation
a0dc954
to
4b43068
Compare
4b43068
to
d5379d0
Compare
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
bz := make([]byte, 8) | ||
|
||
switch command.Command { | ||
case types.AxelarGatewayCommandBurnToken: |
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.
why is there no prefix at all in this case, shouldn't it be 0 or something?
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.
0
is just empty bytes and by doing nothing to bz
, it is. @cgorenflo
if _, err := strconv.ParseInt(keyParticles[0], 10, 64); err != nil { | ||
return fmt.Errorf("expected first key part of %s to be a block height", key) | ||
} |
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.
is this not going to fail with a burn command in the queue?
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.
No it shouldn't. Burn commands' block heights at here are all 0's.
Description
Todos
Steps to Test
Expected Behaviour
Other Notes