Refactor ChanUpgradeInit to use new upgrade type #3456

chatton · 2023-04-13T15:13:59Z

Description

closes: #3447
closes: #3456

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.

…unction

…e-upgrade-type-and-validate-basic-functions

…e-basic-functions' into cian/issue#3451-add-verifiable-upgrade-type-and-validate-basic-functions

modules/core/04-channel/keeper/upgrade.go

chatton · 2023-04-18T10:50:04Z

modules/core/04-channel/keeper/events.go

+			sdk.NewAttribute(types.AttributeKeyUpgradeConnectionHops, upgrade.Fields.ConnectionHops[0]),
+			sdk.NewAttribute(types.AttributeKeyUpgradeVersion, upgrade.Fields.Version),
+			sdk.NewAttribute(types.AttributeKeyUpgradeSequence, fmt.Sprintf("%d", currentChannel.UpgradeSequence)),
+			sdk.NewAttribute(types.AttributeKeyUpgradeOrder, upgrade.Fields.Ordering.String()),


I've added new keys to be explicit about the upgrade fields.

modules/core/04-channel/types/upgrade.go

chatton · 2023-04-18T10:52:15Z

modules/core/keeper/msg_server.go

+func (k Keeper) extractUpgradeFromMessage(ctx sdk.Context, msg *channeltypes.MsgChannelUpgradeInit) (channeltypes.Upgrade, error) {
+	seq, found := k.ChannelKeeper.GetNextSequenceSend(ctx, msg.PortId, msg.ChannelId)
+	if !found {
+		return channeltypes.Upgrade{}, channeltypes.ErrSequenceSendNotFound


I'm unsure if this is the desired behaviour. If we don't want to error here, what value should be set for LatestSequenceSend, 0?

I think if next sequence send is not found then we should error

proto/ibc/core/channel/v1/tx.proto

damiannolan

Really great work pumping this out so quickly with all the various changes ❤️

I left some nits and suggestion/open discussion about the ChanUpgradeInit method sig and return values.

modules/core/04-channel/keeper/upgrade.go

proto/ibc/core/channel/v1/tx.proto

modules/core/keeper/msg_server.go

damiannolan · 2023-04-18T13:46:49Z

modules/core/keeper/msg_server.go

+func (k Keeper) extractUpgradeFromMessage(ctx sdk.Context, msg *channeltypes.MsgChannelUpgradeInit) (channeltypes.Upgrade, error) {
+	seq, found := k.ChannelKeeper.GetNextSequenceSend(ctx, msg.PortId, msg.ChannelId)
+	if !found {
+		return channeltypes.Upgrade{}, channeltypes.ErrSequenceSendNotFound


I think if next sequence send is not found then we should error

modules/core/04-channel/types/upgrade.go

proto/ibc/core/channel/v1/upgrade.proto

modules/core/04-channel/types/events.go

colin-axner

Excellent work!! Code is looking great to me. Left various comments

e2e/tests/core/04-channel/channel_test.go

colin-axner · 2023-04-18T13:27:04Z

modules/core/04-channel/types/msgs_test.go

-				types.Channel{State: types.INITUPGRADE, Version: mock.Version},
-				clienttypes.NewHeight(0, 10000),
-				0,
+				types.NewUpgradeFields(types.UNORDERED, []string{ibctesting.FirstChannelID}, mock.Version),


this should be the connection id?

yes it should be, interesting, we are not validating a valid connection id format in validate basic. Is this something we should be doing?

We could be. Only the first connection ID can be required to be in the "connection-X" format (thinking of multihop non len 1 context). I don't have a strong preference since it will fail on the handler trying to get the connection

proto/ibc/core/channel/v1/upgrade.proto

modules/core/keeper/msg_server.go

modules/core/04-channel/types/upgrade.go

modules/core/04-channel/keeper/upgrade.go

colin-axner · 2023-04-18T16:35:05Z

modules/core/04-channel/keeper/upgrade.go

+			Height:    timeout.Height,
+			Timestamp: timeout.Timestamp,
+		},
+		LatestSequenceSend: seq - 1,


should we add a comment for why we do the minus 1?

We can add a comment if you think it will help, I think the combination of the names GetNextSequenceSend and LatestSequenceSend make it pretty clear, but I can add a comment to make it extra explicit if you think it makes it more clear.

we could also consider adding a new keeper method to sweep it under the rug a little. E.g. k.GetLastSequenceSend(ctx, portID, channelID) which would read the same key/value as GetNextSequenceSend but handle the off by one.

I think if we do that it can be done later in a different PR.

I like @damiannolan's idea!

colin-axner · 2023-04-18T16:36:05Z

modules/core/04-channel/keeper/upgrade.go

-	upgradeSequence uint64,
-	channelUpgrade types.Channel,
-) {
+func (k Keeper) WriteUpgradeInitChannel(ctx sdk.Context, portID, channelID string, currentChannel types.Channel, upgrade types.Upgrade) {


The only thing we have to be careful with about passing in the channel is to ensure it is obtained and not modified in state before calling this function

we could do an additional read of the channel directly in the function, I'm not sure it's necessary though, WDYT?

It is probably safer to do an additional read but I'm also happy to leave as is for now. @colin-axner and I discussed yesterday briefly about refactoring grpc handlers into their associated submodules rather than having the entry point at the core layer. This would mean we could reduce the exported APIs and prevent them from being misused. If this were a private method then it would be much safer passing currentChannel.

I like the idea of doing the additional read for safety and then optimizing later if there's a clean way to do so, but I don't have a strong preference here. Will go with your gut!

crodriguezvega

Looks very clean!

crodriguezvega · 2023-04-19T07:18:46Z

modules/core/04-channel/keeper/upgrade_test.go

-			"invalid proposed channel counterparty",
-			func() {
-				channelUpgrade.Counterparty = types.NewCounterparty(mock.PortID, "channel-100")
+				upgrade.Fields.ConnectionHops = []string{"connection-100"}
 			},
 			false,
 		},
 		{
 			"invalid proposed channel upgrade ordering",


Suggested change

"invalid proposed channel upgrade ordering",

"stricter proposed channel upgrade ordering",

crodriguezvega · 2023-04-19T07:21:30Z

modules/core/04-channel/keeper/events.go

+			sdk.NewAttribute(types.AttributeKeyUpgradeConnectionHops, upgrade.Fields.ConnectionHops[0]),
+			sdk.NewAttribute(types.AttributeKeyUpgradeVersion, upgrade.Fields.Version),
+			sdk.NewAttribute(types.AttributeKeyUpgradeSequence, fmt.Sprintf("%d", currentChannel.UpgradeSequence)),
+			sdk.NewAttribute(types.AttributeKeyUpgradeOrdering, upgrade.Fields.Ordering.String()),


Would be good to add a test for this event, so that if in the future new upgrade fields are added, then the test should fail, so that we don't forget to add the field here. Alternatively, instead of adding each upgrade field with its own key, would it work to have one key for all the upgrade fields and the value is a JSON-encoded string of all of them?

Are you happy if we do this in a followup, I think a few changes would need to happen to the tests (as we are testing the channel keeper function but events are emitted at the message server layer)

crodriguezvega · 2023-04-19T07:29:07Z

modules/core/04-channel/types/msgs.go

 	_, err := sdk.AccAddressFromBech32(msg.Signer)
 	if err != nil {
 		return errorsmod.Wrapf(ibcerrors.ErrInvalidAddress, "string could not be parsed as address: %v", err)
 	}

-	return nil
+	if !msg.Timeout.IsValid() {
+		return errorsmod.Wrap(ErrInvalidUpgrade, "upgrade timeout cannot be empty")


An error message like this would make it similar to the one for Packet.

Suggested change

return errorsmod.Wrap(ErrInvalidUpgrade, "upgrade timeout cannot be empty")

return errorsmod.Wrap(ErrInvalidUpgrade, "upgrade timeout height and upgrade timeout timestamp cannot both be 0")

…ype' of https://github.com/cosmos/ibc-go into cian/issue#3447-modify-upgradeinit-to-use-new-upgrade-type

…e instead of just version

damiannolan

Excellent work ❤️

LGTM!

damiannolan · 2023-04-19T10:25:25Z

modules/core/04-channel/keeper/upgrade.go

-	upgradeSequence uint64,
-	channelUpgrade types.Channel,
-) {
+func (k Keeper) WriteUpgradeInitChannel(ctx sdk.Context, portID, channelID string, currentChannel types.Channel, upgrade types.Upgrade) {


It is probably safer to do an additional read but I'm also happy to leave as is for now. @colin-axner and I discussed yesterday briefly about refactoring grpc handlers into their associated submodules rather than having the entry point at the core layer. This would mean we could reduce the exported APIs and prevent them from being misused. If this were a private method then it would be much safer passing currentChannel.

damiannolan · 2023-04-19T10:28:31Z

modules/core/04-channel/keeper/upgrade.go

+			Height:    timeout.Height,
+			Timestamp: timeout.Timestamp,
+		},
+		LatestSequenceSend: seq - 1,


we could also consider adding a new keeper method to sweep it under the rug a little. E.g. k.GetLastSequenceSend(ctx, portID, channelID) which would read the same key/value as GetNextSequenceSend but handle the off by one.

I think if we do that it can be done later in a different PR.

charleenfei · 2023-04-19T10:32:17Z

modules/core/04-channel/keeper/upgrade_test.go

-			errReceipt, errReceiptPresent := suite.chainA.GetSimApp().IBCKeeper.ChannelKeeper.GetUpgradeErrorReceipt(suite.chainA.GetContext(), path.EndpointA.ChannelConfig.PortID, path.EndpointA.ChannelID)
+			_, err := suite.chainA.GetSimApp().IBCKeeper.ChannelKeeper.ChanUpgradeInit(
+				suite.chainA.GetContext(), path.EndpointA.ChannelConfig.PortID, path.EndpointA.ChannelID, upgrade.Fields, upgrade.Timeout,
+			)

 			if tc.expPass {


we should check that the channel state is in INITUPGRADE now?

colin-axner

Yay! 🎉 Thanks @chatton for pumping this out! :)

modules/core/04-channel/keeper/upgrade_test.go

colin-axner · 2023-04-19T13:00:36Z

modules/core/04-channel/keeper/upgrade.go

-	channel.State = types.INITUPGRADE
-	if reflect.DeepEqual(channel, proposedUpgradeChannel) {
-		return 0, "", errorsmod.Wrap(types.ErrChannelExists, "existing channel end is identical to proposed upgrade channel end")
+	if err := k.ValidateUpgradeFields(ctx, upgradeFields, channel); err != nil {


In a separate pr, how would folks feel about making this function private and placed in upgrade.go?

I think I made the exported as it was used in another package, if it's possible though I'm in favour of making it unexported.

What package? I feel like validation of the upgrade fields against the current fields should only happen in the init and try handlers?

it looks like here

colin-axner and others added 12 commits April 13, 2023 10:50

added validateProposedUpgradeFields function and CheckIsOpen helper f…

995c1f1

…unction

added unit test for CheckIsOpen

f8f6ad4

adding unit tests for ValidateProposedUpgradeFields

808ec70

fix linter

8dd0c44

update to use errorsmod instead of sdk errors

64878ae

added upgrade verification function and unit tests

51bb7a7

improved variable naming

f203df9

Merge branch '04-channel-upgrades' into cian/issue#3445-add-verifiabl…

837e3c9

…e-upgrade-type-and-validate-basic-functions

re-arranged order of test functions

5f9ad67

Merge branch 'cian/issue#3445-add-verifiable-upgrade-type-and-validat…

7bdf33c

…e-basic-functions' into cian/issue#3451-add-verifiable-upgrade-type-and-validate-basic-functions

refactor chan open init

13812eb

removed commented out code

2f7d0fc

charleenfei reviewed Apr 14, 2023

View reviewed changes

modules/core/04-channel/keeper/upgrade.go Show resolved Hide resolved

chatton added 5 commits April 18, 2023 09:59

rename ValidateProposedUpgradeFields to ValidateUpgradeFields

28779f5

merge 04-channel-upgrades

08af922

merge 04-channel-upgrades branch

458b171

refactoring to use new upgrade type

93db50e

removed unused functions and tests

b83849a

chatton marked this pull request as ready for review April 18, 2023 10:49

chatton requested review from AdityaSripal, colin-axner, damiannolan and crodriguezvega as code owners April 18, 2023 10:49

chatton commented Apr 18, 2023

View reviewed changes

remove unnecessary upgrade prefix

f29e2f8

damiannolan reviewed Apr 18, 2023

View reviewed changes

chatton added 2 commits April 18, 2023 15:35

addressing PR feedback

09ddf84

fix linter

8f36c16

colin-axner reviewed Apr 18, 2023

View reviewed changes

fixed logging messages

0b36176

crodriguezvega reviewed Apr 19, 2023

View reviewed changes

chatton added 5 commits April 19, 2023 09:40

wip: pr comments

dfd9be3

Merge branch 'cian/issue#3447-modify-upgradeinit-to-use-new-upgrade-t…

f7eb3dd

…ype' of https://github.com/cosmos/ibc-go into cian/issue#3447-modify-upgradeinit-to-use-new-upgrade-type

pr feedback: use connection id instead of channel id

c631e06

pr feedback: refactor MsgChannelUpgradeInitResponse to contain Upgrad…

b8b5ca4

…e instead of just version

pr feedback: adjusting error messages and test case names

0e8092b

damiannolan approved these changes Apr 19, 2023

View reviewed changes

charleenfei reviewed Apr 19, 2023

View reviewed changes

chatton mentioned this pull request Apr 19, 2023

Add GRPc Query for Upgrade #3491

Merged

9 tasks

colin-axner approved these changes Apr 19, 2023

View reviewed changes

explicitly check for INITUPGRADE state

06b1271

chatton merged commit 81a709b into 04-channel-upgrades Apr 19, 2023

chatton deleted the cian/issue#3447-modify-upgradeinit-to-use-new-upgrade-type branch April 19, 2023 14:30

charleenfei mentioned this pull request Apr 19, 2023

Modify UpgradeInit to use new upgrade type #3447

Closed

3 tasks

chatton mentioned this pull request Apr 20, 2023

Add Unit Tests for Channel Upgrade Event Emission #3497

Closed

3 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Refactor ChanUpgradeInit to use new upgrade type #3456

Refactor ChanUpgradeInit to use new upgrade type #3456

chatton commented Apr 13, 2023 •

edited

Loading

chatton Apr 18, 2023

chatton Apr 18, 2023

damiannolan Apr 18, 2023

damiannolan left a comment

damiannolan Apr 18, 2023

colin-axner left a comment

colin-axner Apr 18, 2023

chatton Apr 19, 2023

colin-axner Apr 19, 2023

colin-axner Apr 18, 2023

chatton Apr 19, 2023

damiannolan Apr 19, 2023

colin-axner Apr 19, 2023

colin-axner Apr 18, 2023

chatton Apr 19, 2023

damiannolan Apr 19, 2023

colin-axner Apr 19, 2023

crodriguezvega left a comment

crodriguezvega Apr 19, 2023

crodriguezvega Apr 19, 2023

chatton Apr 19, 2023

crodriguezvega Apr 19, 2023

damiannolan left a comment

damiannolan Apr 19, 2023

damiannolan Apr 19, 2023

charleenfei Apr 19, 2023

colin-axner left a comment

colin-axner Apr 19, 2023

chatton Apr 19, 2023

colin-axner Apr 19, 2023

chatton Apr 19, 2023

	"invalid proposed channel upgrade ordering",
	"stricter proposed channel upgrade ordering",

	return errorsmod.Wrap(ErrInvalidUpgrade, "upgrade timeout cannot be empty")
	return errorsmod.Wrap(ErrInvalidUpgrade, "upgrade timeout height and upgrade timeout timestamp cannot both be 0")

Refactor ChanUpgradeInit to use new upgrade type #3456

Refactor ChanUpgradeInit to use new upgrade type #3456

Conversation

chatton commented Apr 13, 2023 • edited Loading

Description

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

damiannolan left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

colin-axner left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

crodriguezvega left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

damiannolan left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

colin-axner left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

chatton commented Apr 13, 2023 •

edited

Loading