Skip to content
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

Merged
merged 10 commits into from
Feb 2, 2022

Conversation

jack0son
Copy link
Contributor

@jack0son jack0son commented Jan 16, 2022

Cross referencing command ID to transfer ID in logs was difficult because they were printed in hex and decimal formats respectively.

Description

Todos

  • Unit tests
  • Manual tests
  • Documentation
  • Connect epics/issues
  • Tag type of change

Steps to Test

Expected Behaviour

Other Notes

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)
Copy link
Contributor Author

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.

Copy link
Contributor

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

Copy link
Contributor

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.

Copy link
Contributor Author

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.

@jack0son jack0son requested a review from jcs47 January 16, 2022 02:56
return nil, err
}

s.Logger(ctx).Debug(fmt.Sprintf("signing command batch %s", batchedCommandsIDHex), "commandBatchID", batchedCommandsIDHex, "commandIDHex", commandIDHex, "commandID",
Copy link
Member

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.

Copy link
Member

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

Copy link
Contributor Author

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.

Copy link
Contributor

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

Copy link
Contributor Author

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 ?

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)
Copy link
Contributor

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

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)
Copy link
Contributor

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
types.AttributeKeyChain, chain.Name,
tsstypes.AttributeKeyKeyID, string(commandBatch.GetKeyID()),
"commandBatchID", batchedCommandsIDHex,
"commandID", commandID,
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member

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.

Copy link
Member

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.

Copy link
Contributor Author

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

@@ -9,6 +9,7 @@ const (
EventTypeTokenConfirmation = "tokenConfirmation"
EventTypeTransferKeyConfirmation = "transferKeyConfirmation"
EventTypeLink = "link"
EventTypeStartedSigning = "startedSigning"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
EventTypeStartedSigning = "startedSigning"
EventTypeStartSigning = "startSigning"

nit: the past tense seems superfluous and not really within the current conventions

@@ -9,6 +9,7 @@ const (
EventTypeTokenConfirmation = "tokenConfirmation"
EventTypeTransferKeyConfirmation = "transferKeyConfirmation"
EventTypeLink = "link"
EventTypeStartedSigning = "startedSigning"
Copy link
Contributor

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

@jack0son jack0son enabled auto-merge (squash) January 28, 2022 07:52
Copy link
Member

@milapsheth milapsheth left a 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

@jack0son jack0son merged commit 8e7cbdc into main Feb 2, 2022
@jack0son jack0son deleted the fix/started-signing-event branch February 2, 2022 00:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants