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: packet keys corrupted #7546

Closed

Conversation

gjermundgaraba
Copy link
Contributor

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.

  • Targeted PR against the correct branch (see CONTRIBUTING.md).
  • Linked to GitHub issue with discussion and accepted design, OR link to spec that describes this work.
  • Code follows the module structure standards and Go style guide.
  • Wrote unit and integration tests.
  • Updated relevant documentation (docs/).
  • Added relevant godoc comments.
  • Provide a conventional commit message to follow the repository standards.
  • Include a descriptive changelog entry when appropriate. This may be left to the discretion of the PR reviewers. (e.g. chores should be omitted from changelog)
  • Re-reviewed Files changed in the GitHub PR explorer.
  • Review SonarCloud Report in the comment section below once CI passes.

@gjermundgaraba gjermundgaraba changed the title use numbers in packet keys for now fix: packet keys corrupted Nov 10, 2024
Copy link

)

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

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.

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 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 :)

Copy link
Contributor

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.

Copy link
Contributor

Choose a reason for hiding this comment

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

yup, specifically #7132

Copy link
Contributor Author

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

Copy link
Contributor

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?

@gjermundgaraba
Copy link
Contributor Author

Close in favor of 0050523

@gjermundgaraba gjermundgaraba deleted the gjermund/packet-keys-sequence-fix branch November 12, 2024 13:45
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.

3 participants