-
Notifications
You must be signed in to change notification settings - Fork 610
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
Add ChanUpgradeCancel core handler #3846
Add ChanUpgradeCancel core handler #3846
Conversation
…thub.com/cosmos/ibc-go into cian/issue#3649-implement-restorechannel
…ue#3753-implement-chanupgradecancel-handler-for-04-channel-keeper
…ue#3752-implement-writeupgradecancelchannel
…teupgradecancelchannel
previousState := channel.State | ||
|
||
k.restoreChannel(ctx, portID, channelID, channel) | ||
|
||
k.Logger(ctx).Info("channel state updated", "port-id", portID, "channel-id", channelID, "previous-state", previousState, "new-state", types.OPEN.String()) |
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.
unrelated quick fix to make it consistent with the other write functions.
path.EndpointA.ChannelConfig.ProposedUpgrade.Fields.Version = mock.UpgradeVersion | ||
path.EndpointB.ChannelConfig.ProposedUpgrade.Fields.Version = mock.UpgradeVersion | ||
|
||
err := path.EndpointA.ChanUpgradeInit() |
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.
nit
err := path.EndpointA.ChanUpgradeInit() | |
suite.Require().NoError(path.EndpointA.ChanUpgradeInit()) |
} | ||
|
||
err = path.EndpointB.ChanUpgradeTry() | ||
suite.Require().NoError(err) |
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.
same nit as above
|
||
suite.Require().NoError(path.EndpointB.UpdateClient()) | ||
|
||
// cause the upgrade to fail on chain b so an error receipt is written. |
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.
slick
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.
@damiannolan gets the credit for this one ❤️
return errorsmod.Wrap(types.ErrInvalidUpgradeSequence, "error sequence must be less than current sequence") | ||
} | ||
|
||
channel.UpgradeSequence = errorReceipt.Sequence + 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.
thinking about this more, should we actually update the upgrade sequences in the Write
functions also? this is the one mutation we make in these handler functions. cc @damiannolan @colin-axner
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 did feel a little off, when I was first re-reading what I had written, I was confused for a minute as the channel state didn't change. I think I would be in favour of maybe either returning the desired sequence or just doing the receipt + 1 in the write 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.
As discussed today, I think we can remove the +1 in a followup pr since channel upgrade initialization should bump the upgrade sequence
@@ -47,4 +47,5 @@ var ( | |||
ErrIncompatibleCounterpartyUpgrade = errorsmod.Register(SubModuleName, 31, "incompatible counterparty upgrade") | |||
ErrInvalidUpgradeError = errorsmod.Register(SubModuleName, 32, "invalid upgrade error") | |||
ErrInvalidFlushStatus = errorsmod.Register(SubModuleName, 33, "invalid flush status") | |||
ErrInvalidUpgradeErrorReceipt = errorsmod.Register(SubModuleName, 34, "invalid error receipt") |
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.
are we using this anywhere?
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.
we are not! This actually was introduced when I was doing the empty error receipt check in the keeper function (which was removed since this happens in validate basic.)
We can remove this if we don't do that check.
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, @chatton!
@@ -47,4 +47,5 @@ var ( | |||
ErrIncompatibleCounterpartyUpgrade = errorsmod.Register(SubModuleName, 31, "incompatible counterparty upgrade") | |||
ErrInvalidUpgradeError = errorsmod.Register(SubModuleName, 32, "invalid upgrade error") | |||
ErrInvalidFlushStatus = errorsmod.Register(SubModuleName, 33, "invalid flush status") | |||
ErrInvalidUpgradeErrorReceipt = errorsmod.Register(SubModuleName, 34, "invalid error receipt") |
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.
Is this error actually used?
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 used to be!
…nupgradecancel-handler-for-04-channel-keeper
…-04-channel-keeper' of https://github.com/cosmos/ibc-go into an/issue#3753-implement-chanupgradecancel-handler-for-04-channel-keeper
channel := path.EndpointA.GetChannel() | ||
suite.Require().Equal(errorReceipt.Sequence+1, channel.UpgradeSequence, "upgrade sequence should be incremented") | ||
} else { | ||
suite.Require().ErrorIs(tc.expError, err) |
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.
suite.Require().ErrorIs(tc.expError, err) | |
suite.Require().ErrorIs(err, tc.expError) |
@colin-axner / @damiannolan if you have any concerns about these changes we can include them in #3848 |
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.
LGTM, I can do a followup pr with the small nits/suggestions I found, #3901
currentSequence := channel.UpgradeSequence | ||
counterpartySequence := errorReceipt.Sequence | ||
if counterpartySequence < currentSequence { | ||
return errorsmod.Wrap(types.ErrInvalidUpgradeSequence, "error sequence must be less than current 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.
I think this should say:
error receipt sequence must be greater than or equal to current sequence
And maybe we should add the sequence values?
return errorsmod.Wrap(types.ErrInvalidUpgradeSequence, "error sequence must be less than current sequence") | ||
} | ||
|
||
channel.UpgradeSequence = errorReceipt.Sequence + 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.
As discussed today, I think we can remove the +1 in a followup pr since channel upgrade initialization should bump the upgrade sequence
expError: connectiontypes.ErrConnectionNotFound, | ||
}, | ||
{ | ||
name: "counter partyupgrade sequence less than current 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.
typo, should be:
counterparty upgrade
|
||
suite.chainB.GetSimApp().IBCKeeper.ChannelKeeper.SetUpgradeErrorReceipt(suite.chainB.GetContext(), path.EndpointB.ChannelConfig.PortID, path.EndpointB.ChannelID, errorReceipt) | ||
|
||
suite.coordinator.CommitBlock(suite.chainB) |
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.
context: #3900
When CommitBlock
is called, it commits the current header set within the test chain. This is created on a call to NextBlock
. The state changes are not being reflected to the AppHash
being committed. So when CommitBlock
is being called the first time, it doesn't include the provable state changes (which is why calling it once results in an invalid proof). Committing the current block should reflect the current state changes. We should update it. I think the difficulty is getting the working app hash as this is currently private in the sdk
|
||
suite.chainB.GetSimApp().IBCKeeper.ChannelKeeper.SetUpgradeErrorReceipt(suite.chainB.GetContext(), path.EndpointB.ChannelConfig.PortID, path.EndpointB.ChannelID, errorReceipt) | ||
|
||
suite.coordinator.CommitBlock(suite.chainB) |
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.
The testing pkg has some cleanup in its future. I'd like to simplify the API a bit (there shouldn't be CommitBlock
and NextBlock
)
|
||
suite.Require().NoError(path.EndpointA.ChanUpgradeInit()) | ||
|
||
suite.Require().NoError(path.EndpointB.UpdateClient()) |
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 be removed
Description
Depends on #3752closes: #3753
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.Files changed
in the Github PR explorer.Codecov Report
in the comment section below once CI passes.