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

feat(ica/host)!: migrate ICA host params to be self managed #3520

Merged
merged 75 commits into from
May 23, 2023

Conversation

aleem1314
Copy link
Contributor

@aleem1314 aleem1314 commented Apr 25, 2023

Description

With this PR:

  • The ica/host submodule now self-manages its parameters.
  • Unit and integration tests have been added for the ica/host submodule's parameters.
  • Migration code has been implemented for moving parameters from x/params' subspace to the ica/host submodule's keeper.
  • Migration unit and integration tests have been added.

closes: #3504

addresses: #2010

Commit Message / Changelog Entry

feat(ica/host)!: migrate ica/host to params to be self managed

see the guidelines for commit messages. (view raw markdown for examples)


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.

@codecov-commenter
Copy link

codecov-commenter commented Apr 25, 2023

Codecov Report

Merging #3520 (2eb440c) into main (ba62612) will decrease coverage by 0.05%.
The diff coverage is 64.42%.

❗ Current head 2eb440c differs from pull request most recent head 8586e2e. Consider uploading reports for the commit 8586e2e to get more accurate results

Additional details and impacted files

Impacted file tree graph

@@            Coverage Diff             @@
##             main    #3520      +/-   ##
==========================================
- Coverage   78.80%   78.75%   -0.05%     
==========================================
  Files         182      186       +4     
  Lines       12689    12744      +55     
==========================================
+ Hits         9999    10036      +37     
- Misses       2258     2276      +18     
  Partials      432      432              
Impacted Files Coverage Δ
...es/apps/27-interchain-accounts/host/types/codec.go 0.00% <0.00%> (ø)
...les/apps/27-interchain-accounts/host/types/keys.go 0.00% <ø> (ø)
...27-interchain-accounts/host/types/params_legacy.go 0.00% <0.00%> (ø)
modules/apps/27-interchain-accounts/module.go 53.68% <50.00%> (-0.87%) ⬇️
...s/27-interchain-accounts/host/keeper/migrations.go 78.57% <78.57%> (ø)
...les/apps/27-interchain-accounts/host/types/msgs.go 81.81% <81.81%> (ø)
...les/apps/27-interchain-accounts/host/ibc_module.go 91.11% <100.00%> (ø)
...apps/27-interchain-accounts/host/keeper/genesis.go 90.47% <100.00%> (+1.00%) ⬆️
.../apps/27-interchain-accounts/host/keeper/keeper.go 87.39% <100.00%> (+1.81%) ⬆️
...s/27-interchain-accounts/host/keeper/msg_server.go 100.00% <100.00%> (ø)
... and 2 more

@aleem1314 aleem1314 changed the title feat: migrate ICA host params to be self managed feat!: migrate ICA host params to be self managed May 3, 2023
@aleem1314 aleem1314 marked this pull request as ready for review May 3, 2023 15:12
func (p *Params) ParamSetPairs() paramtypes.ParamSetPairs {
return paramtypes.ParamSetPairs{
paramtypes.NewParamSetPair(KeyHostEnabled, p.HostEnabled, validateEnabledType),
paramtypes.NewParamSetPair(KeyAllowMessages, p.AllowMessages, validateAllowlistLegacy),
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
paramtypes.NewParamSetPair(KeyAllowMessages, p.AllowMessages, validateAllowlistLegacy),
paramtypes.NewParamSetPair(KeyAllowMessages, &p.AllowMessages, validateAllowlistLegacy),

This code should fail during migration unless you use referencing & here. I know because I did the same mistake before. The reason why we both made this mistake was because the original was missing the references.

You would've ran into this error if you wrote migration tests (they would've failed). You should write migration tests. You can use this as an example.

I'm surprised that the e2e tests are passing though as you should be needing to use the new governance proposal to have them update. Did these tests not exist before?

Copy link
Member

Choose a reason for hiding this comment

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

Imo, it makes more sense for these functions to be in keeper.go instead.

Remove the IsHostEnabled function all together, imo, it is wrong to return false if there is a problem unmarshalling. This case should be handled in GetParams, it seems like you're re-implementing GetParams, unnecessary code duplication

Copy link
Member

Choose a reason for hiding this comment

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

You should register the new message in types/codec.go (which you need to create)

Copy link
Member

Choose a reason for hiding this comment

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

You should also initialise the key table for migration in line 915. See example here

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.

Thank you @aleem1314! Really cool that you picked up this work for us 🙏 I left various comments and only had time to review half the pr, I will hopefully pick up my review soon

CHANGELOG.md Outdated Show resolved Hide resolved
modules/apps/27-interchain-accounts/exported/exported.go Outdated Show resolved Hide resolved
modules/apps/27-interchain-accounts/host/keeper/keeper.go Outdated Show resolved Hide resolved
modules/apps/27-interchain-accounts/host/types/keys.go Outdated Show resolved Hide resolved
modules/apps/27-interchain-accounts/module.go Outdated Show resolved Hide resolved
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.

Great work, @aleem1314! I just left a few nits.

modules/apps/27-interchain-accounts/module.go Show resolved Hide resolved

hostm := hostkeeper.NewMigrator(am.hostKeeper)
if err := cfg.RegisterMigration(types.ModuleName, 2, hostm.MigrateParams); err != nil {
panic(fmt.Sprintf("failed to migrate interchainaccounts host params from version 2 to 3: %v", err))
Copy link
Contributor

Choose a reason for hiding this comment

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

Since we will probably migrate together both controller and host params, maybe we can do something here to bump the version only once. But maybe we can deal with that in a later PR after merging also the migration of the controller params.

Suggested change
panic(fmt.Sprintf("failed to migrate interchainaccounts host params from version 2 to 3: %v", err))
panic(fmt.Sprintf("failed to migrate interchainaccounts app from version 2 to 3: %v", err))

Copy link
Member

Choose a reason for hiding this comment

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

done, decided to increase the version now, I assumed the two would be done together but this is safer

Copy link
Member

Choose a reason for hiding this comment

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

Yep, the migration handler can be configured like this with an anonymous function

if err := cfg.RegisterMigration(types.ModuleName, 2, func(ctx sdk.Context) error {
    if err := hostMigrator.MigrateParams(ctx); err != nil {
        return err
    }

    if err := controllerMigrator.MigrateParams(ctx); err != nil {
        return err
    }
}); err != nil {
	panic(fmt.Sprintf("failed to migrate interchainaccounts app from version 2 to 3: %v", err))
}

Copy link
Member

Choose a reason for hiding this comment

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

this can be done later, lgtm

Copy link
Member

@damiannolan damiannolan left a comment

Choose a reason for hiding this comment

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

Thanks @aleem1314 for your work on this, and @srdtrk for seeing it to completion

@colin-axner
Copy link
Contributor

I almost forgot, we need a note in the migration doc for the breaking change in app.go. It should be pretty short with a small diff noting that the authority needs to be added

}

// MsgUpdateParams defines the payload for Msg/UpdateParams
message MsgUpdateParams {
Copy link
Contributor

@DimitrisJim DimitrisJim May 23, 2023

Choose a reason for hiding this comment

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

ah, also, since this is a new file, adding the message signer option or else we'll totally miss it after #3627

Copy link
Member

@srdtrk srdtrk May 23, 2023

Choose a reason for hiding this comment

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

Shouldn't their PRs take care of these when their PR is merging. If I implement it now, it can be confusing. Even if they have to manually resolve the merge conflict. I think it should be fine?

Edit: I misunderstood. I think I will make these additions as commits to that PR, not here. I will be mindful of this in future PRs after their PRs are merged.

import "ibc/applications/interchain_accounts/host/v1/host.proto";

// Msg defines the 27-interchain-accounts/host Msg service.
service Msg {
Copy link
Contributor

Choose a reason for hiding this comment

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

and the equivalent one for services #3630

Copy link
Member

@srdtrk srdtrk May 23, 2023

Choose a reason for hiding this comment

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

Shouldn't their PRs take care of these when their PR is merging. If I implement it now, it can be confusing. Even if they have to manually resolve the merge conflict. I think it should be fine?

Edit: I misunderstood. I think I will make these additions as commits to that PR, not here

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Archived in project
Development

Successfully merging this pull request may close these issues.

Migrate 27-interchain-accounts host params to be self managed
7 participants