-
Notifications
You must be signed in to change notification settings - Fork 3.6k
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
refactor!: Use v1 for gov
and upgrade
proto packages
#9492
Conversation
gov
and update
proto packagesgov
and upgrade
proto packages
gov
and upgrade
proto packagesgov
and upgrade
proto packages
@@ -5,7 +5,7 @@ package cosmos.gov.v1beta1; | |||
import "gogoproto/gogo.proto"; | |||
import "cosmos/gov/v1beta1/gov.proto"; | |||
|
|||
option go_package = "github.com/cosmos/cosmos-sdk/x/gov/types"; | |||
option go_package = "github.com/cosmos/cosmos-sdk/x/gov/legacy/v040"; |
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.
We need gov@v1beta1 still for migrations. I changed their generated path to the legacy folder.
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.
ah, we need it to deserialize Anys?
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.
Yeah, old proposals content have e.g. cosmos.gov.v1beta1.Textproposal
Codecov Report
@@ Coverage Diff @@
## master #9492 +/- ##
===========================================
+ Coverage 35.48% 60.52% +25.03%
===========================================
Files 332 591 +259
Lines 32620 37327 +4707
===========================================
+ Hits 11575 22591 +11016
+ Misses 19819 12787 -7032
- Partials 1226 1949 +723
|
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 cross-referenced that latest v0.42.x proto files and manually tested an upgrade. Overall it looks good. A couple minor observations. Still trying to understand some of the migration changes.
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.
utACK. Left 2 comments.
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.
lgtm
One thing to note is that to query txs by event containing gov Msgs, clients need to query for both versions |
// UpgradedClientState field has been deprecated. IBC upgrade logic has been | ||
// moved to the IBC module in the sub module 02-client. | ||
reserved 5; | ||
reserved "option"; |
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.
Is this still needed? Since it is a new version? Any legacy IBC upgrade mechanisms will use v1beta1
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.
Sure, we can do that. We'll need to add a in-place store migration for x/upgrade.
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.
Isn't the plan deleted after (or even before) the migration?
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.
looks like it would happen right after
I don't have strong opinions on removing/leaving the reserved field. Whatever y'all think is best. Just now seems like a time to do so
They also need to register the legacy Msgs onto their client codec right? I assume only v1 will be registered by default. Maybe add a note of this in the changelog? |
for i, oldProp := range oldProposals { | ||
newProps[i] = types.Proposal{ | ||
ProposalId: oldProp.ProposalId, | ||
Content: oldProp.Content, |
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 you need to migrate the content as well:
Error: error validating genesis file /home/bartleby/.gm/network2/config/genesis.json: failed to unmarshal gov genesis state: unable to resolve type URL /cosmos.upgrade.v1beta1.SoftwareUpgradeProposal
This is from testing genesis export/import and migration using commit b2456e3a2a29
I think you just need to check if oldProp.Content.Type == /cosmos.upgrade.v1beta1.SoftwareUpgradeProposal
and then unmarshal/copy/marshal. Do the store migrations fix this as well? I ran a x/upgrade without this pr, but querying proposals doesn't work now (since the proposal wasn't migrated ofc):
gaiad q gov proposals --node http://localhost:27000
Error: rpc error: code = Unknown desc = rpc error: code = Internal desc = rpc error: code = Internal desc = no concrete type registered for type URL /cosmos.upgrade.v1beta1.SoftwareUpgradeProposal against interface *types.Content: unknown request
Edit:
Thinking about this some more, what happens if a module outside the SDK changes their proposal proto type. Should the gov module add some sort of callback to allow contents to migrate themselves? I ran into a similar issue on IBC since we heavily use Any
s and it seems changing the Any Type
is very problematic
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.
Maybe some sort of registry could work. I register my type url and a function which performs a migration and returns a new Any. So in this case I'd register a function to migrate /cosmos.upgrade.v1beta1.SoftwareUpgradeProposal
to /cosmos.upgrade.v1.SoftwareUpgradeProposal
, then the migration code could just call the registry to perform the migration, if a migration func is registered
Obviously out of scope of this pr, but seems likely the usage of Any
in migrations needs some sort of handling/design
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.
Hmm, good point, I'll add logic to migrate Any
s too from v1beta1
to v1
superseded by #9534, as per #9446 (comment) |
Description
Closes: #9446
Author Checklist
All items are required. Please add a note to the item if the item is not applicable and
please add links to any relevant follow up issues.
I have...
!
to the type prefix if API or client breaking changeCHANGELOG.md
Reviewers Checklist
All items are required. Please add a note if the item is not applicable and please add
your handle next to the items reviewed if you only reviewed selected items.
I have...
!
in the type prefix if API or client breaking change