refactor!: add v2 MerklePath with bytes in favour of strings
#6644
Conversation
damiannolan
requested review from
colin-axner,
AdityaSripal,
chatton,
DimitrisJim,
srdtrk,
crodriguezvega,
gjermundgaraba and
bznein
as code owners
There was a problem hiding this comment.
Maybe you are already planning to do this in a follow-up PR, but looks like many (if not all) of the ...Path functions could be made unexported (or even completely removed and move their code to the corresponding ...Key function.
It would nice also to have changelog :) And document also in the migration docs the change in NewMerklePath.
Yep! I mentioned it on the issue: #6496 (comment) Adding changelog now! |
|
Currently been holding off on merging this until coming to a resolution for wasm e2e test failure. It looks like the change to merkle path means that |
…h existing 08-wasm contracts
damiannolan
requested review from
gjermundgaraba,
crodriguezvega,
chatton and
DimitrisJim
|
Wasm e2e tests got past channel creation which proves the changes are working as expected, unfortunately they are failing for other reasons still. Would be nice to resolve them somehow or turn them off altogether and run when needed... |
| func IsValidUTF8(keyPath [][]byte) bool { | ||
| var key []byte | ||
| for _, bz := range keyPath { | ||
| key = append(key, bz...) |
There was a problem hiding this comment.
each consituent path should be valid utf8 no? This could return early on first non-utf8 valid key path?
There was a problem hiding this comment.
Indeed, I think you're right! We can make that optimisation here 👍🏻 I'll push the change later today.
There was a problem hiding this comment.
Updated in: ba58f37 and added more tests!
| MerklePath *commitmenttypesv2.MerklePath `json:"merkle_path,omitempty"` | ||
| Path commitmenttypes.MerklePath `json:"path"` |
There was a problem hiding this comment.
I guess tradeoff here is pushing a potential migration to the future as opposed to right now?
There was a problem hiding this comment.
Yeah, as I mentioned here #6496 (comment), I'm not too happy about it.
Changing it forces a migration on existing contracts. But I don't see any clear path forward on when you could switch over and fully deprecate the Path field. In fact, I think the longer it stays like this the more disruption it would cause to client contract users, as right now I don't think there is a large amount deployed and in use in prod, whereas if this continues to exist and more are deployed then we are forcing a larger amount of downtime in the event that we actually do change it at some point.
Alternatively, it stays like this forever!
There was a problem hiding this comment.
I don't think we ever had a discussion on versioning the contract api for these sort of situations. Agree that I think this will stay forever or force even more clients to eventually need to migrate.
There was a problem hiding this comment.
Thanks for taking this on @damiannolan! The changes are clean. Agreed the addition of a new field is not ideal, but I think works okay in the short term. At the very least, I don't feel it added much complexity on our side
|
@damiannolan could you please also write some explanation here of the migration needed for contract developers? |
Yes! Can add in a follow up PR. |
|
Description
Follow up to #6633.
v2for ibccommitmentQueryVerifyMembershipmerkle path fieldVerifyMembershipMsgandVerifyNonMembershipMsgwith optional field for non utf8 encoded merkle pathsref: #6496
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/).godoccomments.Files changedin the GitHub PR explorer.SonarCloud Reportin the comment section below once CI passes.