-
Notifications
You must be signed in to change notification settings - Fork 14
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: migrate pundix chain accounts #804
Conversation
WalkthroughThe pull request introduces modifications to the upgrade handling logic within the application. Key changes include the addition of a Changes
Possibly related PRs
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 2
🧹 Outside diff range and nitpick comments (3)
app/upgrade.go (1)
Line range hint
38-42
: Consider adding nil checks for app.appCodec.Since the codec is now being passed to upgrade handlers, we should ensure it's not nil to prevent potential panics during upgrades.
plan.CreateUpgradeHandler( + // Ensure codec is available for upgrade handlers + if app.appCodec == nil { + panic("appCodec is nil when setting up upgrade handlers") + } app.appCodec, app.mm, app.configurator, &app.AppKeepers, ),app/upgrades/v8/pundix.go (2)
69-73
: UseauthRaw
variable consistentlyIn line 72, you're accessing
appState[types.ModuleName]
again, even though you've already assigned it toauthRaw
. To improve consistency and readability, consider using theauthRaw
variable directly.Proposed change:
- if err = m.migrateAuth(ctx, appState[types.ModuleName]); err != nil { + if err = m.migrateAuth(ctx, authRaw); err != nil {
70-70
: Improve error message for missing auth genesis dataThe error message
"auth genesis"
may not provide enough context for troubleshooting. Providing a more descriptive message can aid in debugging.Proposed change:
- return sdkerrors.ErrNotFound.Wrap("auth genesis") + return sdkerrors.ErrNotFound.Wrap("auth genesis data not found in appState")
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (4)
app/upgrade.go
(1 hunks)app/upgrades/types.go
(2 hunks)app/upgrades/v8/pundix.go
(5 hunks)app/upgrades/v8/upgrade.go
(3 hunks)
🔇 Additional comments (7)
app/upgrade.go (1)
Line range hint 38-42
: Verify upgrade handler parameter changes across the codebase.
The addition of app.appCodec
as the first parameter to CreateUpgradeHandler
looks correct. However, we should verify that this change is consistently implemented across all upgrade handlers to prevent runtime panics.
✅ Verification successful
Upgrade handler parameter changes are consistent across the codebase
The verification shows that both the usage in app/upgrade.go
and the implementation in app/upgrades/v8/upgrade.go
consistently handle the codec.Codec
parameter as the first argument to CreateUpgradeHandler
. No inconsistencies or potential runtime issues were found.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify that all CreateUpgradeHandler implementations follow the new signature
# Search for CreateUpgradeHandler implementations
ast-grep --pattern 'CreateUpgradeHandler($$$) {'
# Search for any direct calls to CreateUpgradeHandler
rg -A 3 'CreateUpgradeHandler\('
Length of output: 663
app/upgrades/types.go (2)
6-6
: LGTM: Import addition is appropriate.
The codec import is correctly added to support the new parameter in CreateUpgradeHandler.
22-22
: Verify all upgrade handlers are updated with the new signature.
The addition of the codec parameter is a breaking change that requires updates to all existing upgrade handlers.
Let's verify all upgrade handlers are updated:
Consider adding a comment documenting why the codec parameter was added and its intended use in upgrade handlers. This will help future maintainers understand the design decision.
✅ Verification successful
Let me gather more information to verify if there are any other upgrade handlers in the codebase.
Based on the gathered information, I can now generate the final response:
All upgrade handlers are correctly updated with the new signature
The verification shows that:
- There is only one upgrade handler implementation in
app/upgrades/v8/upgrade.go
which correctly uses the new signature with codec parameter - The usage in
app/upgrade.go
correctly passes the codec parameter - No other upgrade handlers were found in the codebase
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for all CreateUpgradeHandler implementations
ast-grep --pattern 'CreateUpgradeHandler := func($$$) upgradetypes.UpgradeHandler'
# Search for all direct usage of CreateUpgradeHandler
rg "CreateUpgradeHandler\(" -A 2
Length of output: 633
Script:
#!/bin/bash
# Search for all upgrade handler files
fd "upgrade.go" --type f
# Search for any other potential upgrade handler implementations
rg "func.*UpgradeHandler" -A 2
# Search for any other potential CreateUpgradeHandler definitions
rg "type.*Upgrade.*struct" -A 5
Length of output: 9228
app/upgrades/v8/upgrade.go (3)
9-9
: LGTM: Required import for codec parameter.
The addition of the codec import is necessary and correctly placed with other Cosmos SDK imports.
35-35
: LGTM: Signature update follows upgrade handler patterns.
The addition of the codec parameter follows Go conventions and maintains compatibility with the upgrade handler pattern.
Let's verify that other upgrade handlers follow the same pattern:
✅ Verification successful
Let me search for more upgrade handlers to get a complete picture.
Let me check for any previous versions of upgrade handlers to compare the signature change.
Signature change verified and confirmed as a necessary upgrade
The git history shows that the CreateUpgradeHandler
signature was updated from:
func CreateUpgradeHandler(mm *module.Manager, configurator module.Configurator, app *keepers.AppKeepers)
to:
func CreateUpgradeHandler(cdc codec.Codec, mm *module.Manager, configurator module.Configurator, app *keepers.AppKeepers)
The change is necessary as the codec parameter is used in the NewPundix
migration within the upgrade handler. The signature update follows a consistent pattern and maintains backward compatibility.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check other upgrade handlers for consistency
rg -g '*/upgrades/*/upgrade.go' -A 2 'func CreateUpgradeHandler'
Length of output: 475
Script:
#!/bin/bash
# Search for all upgrade.go files and their content
fd 'upgrade.go' --exec cat {}
Length of output: 8699
Script:
#!/bin/bash
# Check git history for previous versions of upgrade handlers
git log -p --all | rg -A 3 "func CreateUpgradeHandler"
Length of output: 972
59-61
: Verify migration order dependencies.
The Pundix migration is positioned after store cleanup and gov params migration, but before bridge balance migration. Please verify that this order is correct and there are no dependencies that would require a different sequence.
Let's check for any dependencies in the Pundix migration:
✅ Verification successful
Let me gather more information about the dependencies and migration flow.
Let me check one more aspect to understand the dependencies between migrations.
Based on the gathered information, I can now provide the final response:
Migration order is correctly positioned
The Pundix migration's position is appropriate because:
- It handles auth and bank state migrations from genesis data
- It runs after store cleanup and gov params which don't affect its operation
- The subsequent bridge balance migration depends on having the correct token balances in place, which this migration provides by migrating PUNDIX and PURSE tokens
- No circular dependencies are present in the migration chain
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Look for dependencies in Pundix migration implementation
rg -A 10 'type Pundix struct' app/upgrades/v8/
rg -A 10 'func.*Migrate' app/upgrades/v8/pundix.go
Length of output: 1115
Script:
#!/bin/bash
# Check what the Pundix migration actually does
rg -A 20 'func \(m \*Pundix\) Migrate' app/upgrades/v8/pundix.go
# Check for any dependencies on this migration in other files
rg -l "NewPundix" app/upgrades/v8/
# Look at the full upgrade handler to understand the migration sequence
rg -A 30 'func CreateUpgradeHandler' app/upgrades/v8/upgrade.go
Length of output: 2060
Script:
#!/bin/bash
# Check what the auth and bank migrations do to understand dependencies
rg -A 10 'func \(m \*Pundix\) migrateAuth' app/upgrades/v8/pundix.go
rg -A 10 'func \(m \*Pundix\) migrateBank' app/upgrades/v8/pundix.go
# Check what the bridge balance migration does since it comes after
rg -A 10 'func migrateBridgeBalance' app/upgrades/v8/
Length of output: 1779
app/upgrades/v8/pundix.go (1)
49-53
: Ensure all invocations of NewPundix
are updated with the new signature
The constructor NewPundix
now requires an additional cdc codec.Codec
parameter. Ensure that all instances where NewPundix
is called are updated to pass the appropriate cdc
to prevent compilation errors.
You can run the following script to find all calls to NewPundix
that may need updating:
✅ Verification successful
Based on the search results, I can generate the final response as we have found all instances of NewPundix
usage in the codebase:
NewPundix
constructor usage is already correctly updated
The only invocation of NewPundix
found in the codebase is in app/upgrades/v8/upgrade.go
and it's already passing the cdc
parameter correctly: NewPundix(cdc, app)
. No further updates are needed.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Find all calls to `NewPundix` and verify the correct number of arguments.
# Expected result: All calls to `NewPundix` should include the `cdc` parameter.
rg 'NewPundix\(' --context 2
Length of output: 505
Summary by CodeRabbit
New Features
auth
andbank
modules, ensuring accurate data handling during upgrades.Bug Fixes
auth
module's genesis state during migration.Documentation