-
Notifications
You must be signed in to change notification settings - Fork 241
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
Problem: ethermint v0.9.0 is not used #241
Conversation
Closes: crypto-org-chain#238 Solution: - update ethermint dependency. - use a constant mock feemarket keeper for now.
I think we will need to increment the version for the upgrade handler as well |
Added an upgrade handler for the next major version number |
Codecov Report
@@ Coverage Diff @@
## main #241 +/- ##
==========================================
+ Coverage 21.51% 24.80% +3.29%
==========================================
Files 27 34 +7
Lines 1729 2572 +843
==========================================
+ Hits 372 638 +266
- Misses 1324 1887 +563
- Partials 33 47 +14
Continue to review full report at Codecov.
|
integration tests passed. |
is it still a draft? |
changed, it's ready for review and merge. |
replace github.com/tharsis/ethermint => github.com/crypto-org-chain/ethermint v0.6.1-0.20211207040748-254df3803d62 |
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.
replace github.com/tharsis/ethermint => github.com/crypto-org-chain/ethermint v0.6.1-0.20211207040748-254df3803d62 | |
// https://github.com/crypto-org-chain/ethermint/tree/v0.9.x-cronos | |
replace github.com/tharsis/ethermint => github.com/crypto-org-chain/ethermint v0.6.1-0.20211207040748-254df3803d62 |
lgtm @tomtau could you review the upgrade section part? I think no there is no migration to be done on ethermint side |
// upgrade handler | ||
plan0_7_0 := "v0.7.0" | ||
app.UpgradeKeeper.SetUpgradeHandler(plan0_7_0, func(ctx sdk.Context, plan upgradetypes.Plan, fromVM module.VersionMap) (module.VersionMap, error) { | ||
return app.mm.RunMigrations(ctx, app.configurator, fromVM) |
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.
not sure if the ibc-go module version increased? https://github.com/cosmos/ibc-go/blob/main/modules/core/module.go#L164
there isn't much change between ibc-go 1 and 2, but not sure whether one shouldn't explicitly pass it in the upgrade handler so that the version map gets upgraded for the future
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.
I think the fromVM
is loaded from the storage, and RunMigrations
will migrate them to current version automatically, so it should work?
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.
if that's desirable with the fork to upstream migration later (I'm assuming when it adds the hooks or middleware, it'll be increased to 3?)
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.
if that's desirable with the fork to upstream migration later (I'm assuming when it adds the hooks or middleware, it'll be increased to 3?)
do you mean the cronos module? I think if there's nothing to migrate in the storage, there's no need to increase the consensus version, right?
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.
I meant the ibc-go fork. ConsensusVersion in a module should be increased with any state-breaking changes, so hopefully it's fine
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.
I think fee market has some on-chain parameters, so maybe those should be initialised in the upgrade handler?
|
but fromVM will contain the old store's version map, not the one being migrated to? |
|
ok, and is feemarket's |
Hmm, that's sth need to be aware of, the default |
go.mod
Outdated
|
||
replace github.com/cosmos/iavl => github.com/cosmos/iavl v0.17.1 | ||
replace github.com/cosmos/iavl => github.com/cosmos/iavl v0.17.2 |
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.
v0.17.2 had some race condition / concurrent access issues -- not sure if this can manifest in Ethermint / Web3 APIs: cosmos/iavl@v0.17.2...v0.17.3 but perhaps better to use the latest one?
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.
updated
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.
the mainnet beta upgrade should be better planned, so for the feemarket network param value, the upgrade handler can be later adjusted
can you add an entry on the changelog? |
done |
Closes: #238
Solution:
👮🏻👮🏻👮🏻 !!!! REFERENCE THE PROBLEM YOUR ARE SOLVING IN THE PR TITLE AND DESCRIBE YOUR SOLUTION HERE !!!! DO NOT FORGET !!!! 👮🏻👮🏻👮🏻
PR Checklist:
make
)make test
)go fmt
)golangci-lint run
)go list -json -m all | nancy sleuth
)Thank you for your code, it's appreciated! :)