-
Notifications
You must be signed in to change notification settings - Fork 3.6k
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
Upgrade Client #7367
Upgrade Client #7367
Conversation
Codecov Report
@@ Coverage Diff @@
## master #7367 +/- ##
==========================================
+ Coverage 54.81% 54.96% +0.14%
==========================================
Files 587 588 +1
Lines 36512 36630 +118
==========================================
+ Hits 20014 20133 +119
- Misses 14406 14408 +2
+ Partials 2092 2089 -3 |
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.
Looks good! thanks for the additional tests. Pending lint and test fixes
var height = clienttypes.NewHeight(0, 4) | ||
var ( | ||
height = clienttypes.NewHeight(0, 4) | ||
upgradeHeight = clienttypes.NewHeight(1, 1) |
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.
can we define these on ibctesting instead?
Co-authored-by: Federico Kunze <[email protected]>
…into aditya-upgrade-client
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.
Fantastic work!!! This is a solid feature and super neat that it is integrated with the upgrade module!
Left mostly comments on increasing code cov. LGTM though
Name: "alt-good", | ||
Info: "new text here", | ||
Height: 543210000, | ||
UpgradedClientState: altCs, |
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 should overwrite with non IBC plan so the upgrade client state should be nil 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.
Correct, as mentioned in test case name
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'm confused? Why is UpgradedClientState: altCs
set then?
func (p Plan) String() string { | ||
due := p.DueAt() | ||
dueUp := strings.ToUpper(due[0:1]) + due[1:] | ||
var upgradedClientStr string | ||
upgradedClient, err := clienttypes.UnpackClientState(p.UpgradedClientState) |
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'd suggest checking if p.UpgradedClientState != nil
instead of allowing unpack with a nil client state. The err on unpacking could be return instead of no upgraded client provided
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.
Can't return an error because that would break fmt.Stringer
interface
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.
why can't you set upgradedClientStr = err.Error()
?
// UnpackInterfaces implements UnpackInterfacesMessage.UnpackInterfaces | ||
func (p Plan) UnpackInterfaces(unpacker codectypes.AnyUnpacker) error { | ||
// UpgradedClientState may be nil | ||
if p.UpgradedClientState == nil { |
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.
see above comment, this seems unnecessary. I'm a little confused why unpack doesn't succeed if this returns nil as well
…into aditya-upgrade-client
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.
ACK. Pending minor test cases. Great work!
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.
Unless I'm missing something, we're not validating the non-zeroed-fields?
|
||
// counterparty chain must commit the upgraded client with all client-customizable fields zeroed out | ||
// at the upgrade path specified by current client | ||
committedClient := upgradedClient.ZeroCustomFields() |
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.
Where do we check that the non-zeroed-out fields correspond to the old (current) fields? The relayer shouldn't be choosing these
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.
It's not generally possible because the client state structure may have changed. I just check that the chosen fields are consistent with unchosen fields.
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.
Can't the relayer change the trusting ratio or something then? Are we preventing that somewhere?
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 issue here is the client state could change to something radically different (a solo machine client is used in testing) which may not have a trusting ratio?
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.
hmm, that would be alright, but we still can't let the relayer change these fields in e.g. a Tendermint to Tendermint upgrade
Description
closes: #6378
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