-
Notifications
You must be signed in to change notification settings - Fork 636
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: packet keys corrupted #7546
Conversation
Quality Gate passed for 'ibc-go'Issues Measures |
) | ||
|
||
// PacketReceiptKey returns the store key of under which a packet | ||
// receipt is stored | ||
func PacketReceiptKey(channelID string, sequence uint64) []byte { | ||
return []byte(fmt.Sprintf("receipts/channels/%s/sequences/%s", channelID, sdk.Uint64ToBigEndian(sequence))) | ||
return []byte(fmt.Sprintf("receipts/channels/%s/sequences/%d", channelID, sequence)) |
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.
wdym by corrupted? String value for key is only intermediate repr before casting to bytes, no? Is there missing context whereby we care about string value for these?
Looking at spec, these will continue using BigEndian encoding for seqs to keep sorted order.
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 is what the string ends up looking like: "acks/channels/channel-0/sequences/\x00\x00\x00\x00\x00\x00\x00\x01
and it creates some issues with our relayer. It should technically not be a huge problem, but I can't imagine this being the idea of what is should look like at least :)
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 think the main reason for doing this was to make it so iteration over channel IDs/ sequences etc happens in an expected order, rather than lexicographically. We are doing this also in the PacketForwardKey fn.
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.
yup, specifically #7132
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.
Alright, so we want it to look like this? If so, I can go back and figure out a way to deal with those characters in the operator cli
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.
yea. Can't you just decode the byte slice into the number where needed?
Close in favor of 0050523 |
Description
I think we will change the format to use bytes later (?), but the current setup gave problems because the byte array for big endian didn't stringify very well. So until we get the packet keys sorted, this will at least work.
closes: #XXXX
Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.
docs/
).godoc
comments.Files changed
in the GitHub PR explorer.SonarCloud Report
in the comment section below once CI passes.