-
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
fix(evm): define 'startedSigning' event name and print command ID decimal #1219
Conversation
x/evm/keeper/msg_server.go
Outdated
for _, commandID := range commandList { | ||
s.Logger(ctx).Debug("signing command batch", "commandBatchID", batchedCommandsIDHex, "commandID", commandID) | ||
for _, commandIDHex := range commandList { | ||
commandID, err := strconv.ParseUint(commandIDHex, 16, 64) |
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.
@jcs47 I made a mistake here - ParseUint expects bit size not byte size.
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 convert to uint? not all command id origins from transfer id
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.
Same question. Also, these command IDs are of bytes32
in the contracts which means it would overflow for ParseUint
.
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 was a naive quick fix to try and address the mapping issue on call 😢. Reverting.
x/evm/keeper/msg_server.go
Outdated
return nil, err | ||
} | ||
|
||
s.Logger(ctx).Debug(fmt.Sprintf("signing command batch %s", batchedCommandsIDHex), "commandBatchID", batchedCommandsIDHex, "commandIDHex", commandIDHex, "commandID", |
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.
Haha, related fix: https://github.com/axelarnetwork/axelar-core/pull/1220/files#diff-4a401bcb508aac66739d477b623d017e5d9aa737701e568f8f947775965938d7R1465
I prefer adding the values in the log itself rather than attributes since it's much easier to search datadog with that.
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 can drop my line change here if you wanna combine that logic
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.
Think we should always at minimum have attributes as the formal method for querying logs. Prefer to have both as logging some info in the message makes quick searches easier.
Need to agree on these points in the issue you made.
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.
facets definitely seem like the best way to correlate logs through various stages since it doesn't require the user to add that key value information into the message string itself and is automatically appended to every message within a given stage, but I will say that a downside is if we get into a situation where we are using many different facet names for the same information, forcing us to union many different facets to get a complete picture versus just being able to search for one string value. that being said, we just need to coordinate on naming conventions (how to capitalize, when to use underscores, etc) -- it may be useful to have a sort of internal library that can codify some of these standards, but we can flesh that requirement out more down the line once more of these multi-facets appear and we have a real need for it
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.
👍 👍 👍 could you please add this comment here #1227 @wilcollins ?
x/evm/keeper/msg_server.go
Outdated
for _, commandID := range commandList { | ||
s.Logger(ctx).Debug("signing command batch", "commandBatchID", batchedCommandsIDHex, "commandID", commandID) | ||
for _, commandIDHex := range commandList { | ||
commandID, err := strconv.ParseUint(commandIDHex, 16, 64) |
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 convert to uint? not all command id origins from transfer id
x/evm/keeper/msg_server.go
Outdated
for _, commandID := range commandList { | ||
s.Logger(ctx).Debug("signing command batch", "commandBatchID", batchedCommandsIDHex, "commandID", commandID) | ||
for _, commandIDHex := range commandList { | ||
commandID, err := strconv.ParseUint(commandIDHex, 16, 64) |
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.
Same question. Also, these command IDs are of bytes32
in the contracts which means it would overflow for ParseUint
.
…imal add batch id to message content strconv.ParseUint uses bit size NOT byte size revert commandID hex -> uint conversion
23ec2a9
to
144437e
Compare
types.AttributeKeyChain, chain.Name, | ||
tsstypes.AttributeKeyKeyID, string(commandBatch.GetKeyID()), | ||
"commandBatchID", batchedCommandsIDHex, | ||
"commandID", commandID, |
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.
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.
Can we please keep the values in the log message for now? We should refactor logs at the same time for consistency, otherwise it's gonna be harder during debugging.
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'm not sure if the logging refactor will go in to the next ERC-20 release.
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.
Reverted to the original log message with the attributes included as well
x/evm/types/events.go
Outdated
@@ -9,6 +9,7 @@ const ( | |||
EventTypeTokenConfirmation = "tokenConfirmation" | |||
EventTypeTransferKeyConfirmation = "transferKeyConfirmation" | |||
EventTypeLink = "link" | |||
EventTypeStartedSigning = "startedSigning" |
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.
EventTypeStartedSigning = "startedSigning" | |
EventTypeStartSigning = "startSigning" |
nit: the past tense seems superfluous and not really within the current conventions
x/evm/types/events.go
Outdated
@@ -9,6 +9,7 @@ const ( | |||
EventTypeTokenConfirmation = "tokenConfirmation" | |||
EventTypeTransferKeyConfirmation = "transferKeyConfirmation" | |||
EventTypeLink = "link" | |||
EventTypeStartedSigning = "startedSigning" |
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.
event type should be sign
and action should be start
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.
Don't want to change the log style until the grand refactor
Cross referencing command ID to transfer ID in logs was difficult because they were printed in hex and decimal formats respectively.
Description
Todos
Steps to Test
Expected Behaviour
Other Notes