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

Add ChanUpgradeCancel core handler #3846

Conversation

chatton
Copy link
Contributor

@chatton chatton commented Jun 14, 2023

Description

Depends on #3752

closes: #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.

  • Targeted PR against 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/) or specification (x/<module>/spec/).
  • Added relevant godoc comments.
  • Provide a commit message to be used for the changelog entry in the PR description for review.
  • Re-reviewed Files changed in the Github PR explorer.
  • Review Codecov Report in the comment section below once CI passes.

chatton and others added 30 commits June 1, 2023 16:40
…ue#3753-implement-chanupgradecancel-handler-for-04-channel-keeper
Comment on lines +284 to +288
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())
Copy link
Contributor Author

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.

@chatton chatton marked this pull request as ready for review June 14, 2023 15:04
@crodriguezvega crodriguezvega changed the title Add ChanUpgradeCancel handler Add ChanUpgradeCancel core handler Jun 15, 2023
modules/core/04-channel/keeper/upgrade.go Show resolved Hide resolved
modules/core/04-channel/keeper/upgrade.go Show resolved Hide resolved
modules/core/04-channel/keeper/upgrade.go Show resolved Hide resolved
modules/core/04-channel/keeper/upgrade.go Outdated Show resolved Hide resolved
modules/core/04-channel/keeper/upgrade.go Show resolved Hide resolved
path.EndpointA.ChannelConfig.ProposedUpgrade.Fields.Version = mock.UpgradeVersion
path.EndpointB.ChannelConfig.ProposedUpgrade.Fields.Version = mock.UpgradeVersion

err := path.EndpointA.ChanUpgradeInit()
Copy link
Contributor

Choose a reason for hiding this comment

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

nit

Suggested change
err := path.EndpointA.ChanUpgradeInit()
suite.Require().NoError(path.EndpointA.ChanUpgradeInit())

}

err = path.EndpointB.ChanUpgradeTry()
suite.Require().NoError(err)
Copy link
Contributor

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.
Copy link
Contributor

Choose a reason for hiding this comment

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

slick

Copy link
Contributor Author

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

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

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 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.

Copy link
Contributor

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

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?

Copy link
Contributor Author

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.

Copy link
Contributor

@crodriguezvega crodriguezvega left a comment

Choose a reason for hiding this comment

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

Looks good, @chatton!

modules/core/04-channel/keeper/upgrade_test.go Outdated Show resolved Hide resolved
@@ -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")
Copy link
Contributor

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?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

chatton and others added 3 commits June 16, 2023 09:32
…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)
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
suite.Require().ErrorIs(tc.expError, err)
suite.Require().ErrorIs(err, tc.expError)

@chatton chatton merged commit c0943cc into 04-channel-upgrades Jun 16, 2023
46 checks passed
@chatton chatton deleted the cian/issue#3753-implement-chanupgradecancel-handler-for-04-channel-keeper branch June 16, 2023 13:11
@chatton
Copy link
Contributor Author

chatton commented Jun 16, 2023

@colin-axner / @damiannolan if you have any concerns about these changes we can include them in #3848

Copy link
Contributor

@colin-axner colin-axner left a 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")
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 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
Copy link
Contributor

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",
Copy link
Contributor

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

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

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

Choose a reason for hiding this comment

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

can be removed

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.

4 participants