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

chore: implement msg server for ChannelUpgradeTry #3791

Merged

Conversation

damiannolan
Copy link
Member

@damiannolan damiannolan commented Jun 7, 2023

Description

Adding msg server implementation for ChannelUpgradeTry.
NOTE: testing app changes have been pulled out to #3812

closes: #3740


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.

@@ -203,6 +203,10 @@ func (k Keeper) WriteUpgradeTryChannel(
emitChannelUpgradeTryEvent(ctx, portID, channelID, channel, proposedUpgrade)
}

func (k Keeper) AbortUpgrade(ctx sdk.Context, portID, channelID string, err error) error {
Copy link
Member Author

Choose a reason for hiding this comment

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

Pending #3728

Base automatically changed from colin/3739-upgrade-try-handler to 04-channel-upgrades June 8, 2023 09:37
Comment on lines +193 to +194
// TODO: determine flush status
// channel.FlushStatus = flushStatus
Copy link
Member Author

Choose a reason for hiding this comment

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

should be addressed in a future PR.

proposedUpgrade types.Upgrade,
flushStatus types.FlushStatus,
) {
func (k Keeper) WriteUpgradeTryChannel(ctx sdk.Context, portID, channelID string, upgrade types.Upgrade, upgradeVersion string) {
Copy link
Member Author

Choose a reason for hiding this comment

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

I can open another PR to replicate this on INIT - accepting the upgradeVersion as an arg and updating the upgrade inside this method as opposed to in the msg server

Copy link
Contributor

Choose a reason for hiding this comment

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

+1 for mutations in one function. Docstring could also mention that we set the upgrade in addition to the channel.

return nil, err
}

cacheCtx, writeFn := ctx.CacheContext()
Copy link
Member Author

Choose a reason for hiding this comment

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

state changes made the by app are not committed on error of the app callback, and instead, an error receipt is written for the current upgrade sequence.

@damiannolan damiannolan changed the title [wip] scaffold msg server for chanUpgradeTry chore: implement msg server for ChannelUpgradeTry Jun 11, 2023
Comment on lines 797 to 801
return &channeltypes.MsgChannelUpgradeTryResponse{
Result: channeltypes.SUCCESS,
ChannelId: msg.ChannelId,
Upgrade: upgrade,
}, nil
Copy link
Member Author

Choose a reason for hiding this comment

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

Upgrade sequence is defined in the response but requires a channel lookup in the msg server as its no longer returned from ChanUpgradeTry. I'm not a massive fan of doing that lookup at this level. Upgrade sequence is still emitted in events.

anyone have any thoughts on this?

Copy link
Member

Choose a reason for hiding this comment

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

Im ok with removing that from response

Copy link
Contributor

Choose a reason for hiding this comment

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

I agree with not doing the lookup here, but maybe we could abstract into a function:

return formatUpgradeTrySuccessResponse()

or something. No strong preference, happy to remove now and add in the future upon request

upgradeVersion, err := cbs.OnChanUpgradeTry(cacheCtx, msg.PortId, msg.ChannelId, upgrade.Fields.Ordering, upgrade.Fields.ConnectionHops, upgrade.Fields.Version)
if err != nil {
if err := k.ChannelKeeper.AbortUpgrade(ctx, msg.PortId, msg.ChannelId, err); err != nil {
return nil, err
Copy link
Contributor

Choose a reason for hiding this comment

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

guess we should also be logging this error case? Similarly log a successful upgradetry before we return in 796.

return &channeltypes.MsgChannelUpgradeTryResponse{
Result: channeltypes.SUCCESS,
ChannelId: msg.ChannelId,
Upgrade: upgrade,
Copy link
Member

Choose a reason for hiding this comment

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

It looks like this will return an upgrade with the passed-in version. Doesn't it make sense to return with the version set by callback?

Copy link
Member Author

Choose a reason for hiding this comment

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

aha, yes indeed! nice catch

Copy link
Contributor

Choose a reason for hiding this comment

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

Agreed. Upgrade set here should have updated version

Copy link
Member Author

Choose a reason for hiding this comment

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

Two potential ways of handling this:

  1. pass Upgrade to the WriteUpgradeTryChannel method as a reference, pointer type.
  2. Return the Upgrade or even possibly the entire response from the WriteUpgradeTryChannel method.

do you guys favour either?

Copy link
Member Author

Choose a reason for hiding this comment

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

We could also go for this returning the upgrade and the sequence for the response

func (k Keeper) WriteUpgradeTryChannel(...) (Upgrade, uint64)

Copy link
Member

Choose a reason for hiding this comment

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

You could return the entire response I think

Copy link
Member Author

Choose a reason for hiding this comment

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

Yeah, opted for going with returning (Channel, Upgrade) for now, opened #3825

Comment on lines 797 to 801
return &channeltypes.MsgChannelUpgradeTryResponse{
Result: channeltypes.SUCCESS,
ChannelId: msg.ChannelId,
Upgrade: upgrade,
}, nil
Copy link
Member

Choose a reason for hiding this comment

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

Im ok with removing that from response

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.

Ay! Looks super clean! I left several suggestions, but happy to push any you agree with into issues and handle them in followups

modules/core/keeper/msg_server.go Show resolved Hide resolved
modules/core/keeper/msg_server.go Show resolved Hide resolved
modules/core/keeper/msg_server.go Show resolved Hide resolved
return &channeltypes.MsgChannelUpgradeTryResponse{
Result: channeltypes.SUCCESS,
ChannelId: msg.ChannelId,
Upgrade: upgrade,
Copy link
Contributor

Choose a reason for hiding this comment

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

Agreed. Upgrade set here should have updated version

Comment on lines 797 to 801
return &channeltypes.MsgChannelUpgradeTryResponse{
Result: channeltypes.SUCCESS,
ChannelId: msg.ChannelId,
Upgrade: upgrade,
}, nil
Copy link
Contributor

Choose a reason for hiding this comment

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

I agree with not doing the lookup here, but maybe we could abstract into a function:

return formatUpgradeTrySuccessResponse()

or something. No strong preference, happy to remove now and add in the future upon request

modules/core/keeper/msg_server_test.go Show resolved Hide resolved
modules/core/keeper/msg_server_test.go Outdated Show resolved Hide resolved
Copy link
Contributor

@chatton chatton left a comment

Choose a reason for hiding this comment

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

Nice job this looks great! There were just a few small nits but I don't think anything should block this going forward. Main thing to change that's been pointed out is making sure the correct version is returned in the response 👍

modules/core/keeper/msg_server.go Show resolved Hide resolved
modules/core/keeper/msg_server.go Show resolved Hide resolved
modules/core/keeper/msg_server.go Show resolved Hide resolved
cases := []struct {
name string
malleate func()
expResult func(res *channeltypes.MsgChannelUpgradeTryResponse, err error)
Copy link
Contributor

Choose a reason for hiding this comment

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

[nit] usually I would imagine expResult is the expected result, but this is an assertion function. Maybe assertionFn?

Copy link
Member Author

Choose a reason for hiding this comment

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

that's a fair point, I think we have this test setup in some extra places in the codebase using expResult, so maybe we can do one swoop to change all if people feel its worth it.

(I know we have inconsistencies with expPass, expError and expResult in different places - maybe we can keep some housekeeping work for a rainy day (?))

Copy link
Contributor

Choose a reason for hiding this comment

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

assertionFn sounds nice to me. Agree it should be done in a single swoop

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.

Followup ACK

Copy link
Contributor

@chatton chatton left a comment

Choose a reason for hiding this comment

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

Followup ACK 👍

@damiannolan damiannolan merged commit 9718a71 into 04-channel-upgrades Jun 12, 2023
@damiannolan damiannolan deleted the damian/3740-chan-upgrade-try-msg-server branch June 12, 2023 14:03
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.

5 participants