-
Notifications
You must be signed in to change notification settings - Fork 586
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
refactor: replace usage of verification funcs in 03-connection #1647
refactor: replace usage of verification funcs in 03-connection #1647
Conversation
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.
Nice work @damiannolan !
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.
Great work!
See comments regarding time/block delay. Since we are hard coding 0, 0
, I think it might be worth adding some more code docs/test cases to ensure it doesn't get accidentally changed in the future
|
||
if err := targetClient.VerifyMembership( | ||
ctx, clientStore, k.cdc, height, | ||
0, 0, |
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.
might be nice to add an inline comment for future readers:
0, 0, // skip delay period checks for non-packet processing verification
or something along those lines
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.
Do you think we should add test cases for each of the verify functions with the time/block delay periods set to 0. That is, add test cases which will normally fail on the delay period not being passed (if 0, 0, isn't passed in). Thoughts?
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.
Great idea, I'll add the inline comment.
add test cases which will normally fail on the delay period not being passed (if 0, 0, isn't passed in)
So if 0, 0, isn't passed in here it won't fail? there's nothing at the lightclient level which would return an error, and it needs to be generic to support both zero values and non zero values for delay periods, right?
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.
Let's address this with a follow up if needs be.
* removing legacy verify funcs from clientstate interface * chore: remove legacy verify funcs tm client (#1651) * removing legacy verification methods from tendermint client * removing commented out tests
…s#1647) * replacing 03-connection verifications with generic membership methods * adding inline comments for skipping delay period checks * chore: removing legacy verify funcs from `ClientState` interface (cosmos#1649) * removing legacy verify funcs from clientstate interface * chore: remove legacy verify funcs tm client (cosmos#1651) * removing legacy verification methods from tendermint client * removing commented out tests * fixing interface definition
Description
Replacing usage of:
VerifyClientState
VerifyConsensusState
VerifyConnection
VerifyChannel
VerifyPacketCommitment
VerifyAcknowledgement
VerifyPacketReceipt
VerifyPacketReceiptAbsence
with the generic
VerifyMembership
andVerifyNonMembership
functions.closes: #1293
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/
) or specification (x/<module>/spec/
)godoc
comments.Unreleased
section inCHANGELOG.md
Files changed
in the Github PR explorerCodecov Report
in the comment section below once CI passes