Howevever since this new configurator doesn't have access to the migrations registered in the first one when trying to upgrade the chain there is a panic: panic: no migrations found for module bank: not found
I fixed this by making a global variable named appcfg, storing the original configurator there and reusing it in app.mm.RunMigrations(ctx, appcfg, fromVM)
Wouldn't it make sense to store this configurator in the App struct and referencing it as app.cfg?
https://github.com/tendermint/starport/blob/a8409909345459103872c5070bd23ce552c82429/starport/templates/app/stargate/app/app.go.plush#L427
This line creates a new configurator that isn't stored anywhere.
The Cosmos docs says to create another new configurator when registering upgrade handlers: https://docs.cosmos.network/master/core/upgrade.html#running-migrations (note there is a typo here where
app.mm.RunMigrations(ctx, cfg, fromVM)
is written asapp.mm.RunMigrations(ctx, fromVM)
)Howevever since this new configurator doesn't have access to the migrations registered in the first one when trying to upgrade the chain there is a panic:
panic: no migrations found for module bank: not found
I fixed this by making a global variable named
appcfg
, storing the original configurator there and reusing it inapp.mm.RunMigrations(ctx, appcfg, fromVM)
Wouldn't it make sense to store this configurator in the App struct and referencing it as
app.cfg
?