-
Notifications
You must be signed in to change notification settings - Fork 3.7k
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: implement new gov msg & query servers #10868
Conversation
x/gov/module.go
Outdated
v1beta2.RegisterMsgServer(cfg.MsgServer(), keeper.NewMsgServerImpl(am.keeper)) | ||
v1beta2.RegisterQueryServer(cfg.QueryServer(), am.keeper) |
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.
Should we add v1beta1 too, for backwards-compatibility?
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.
Yes sorry, we want both.
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.
TO not overload this PR, I created a spearate issue for query: #10951
Codecov Report
@@ Coverage Diff @@
## master #10868 +/- ##
==========================================
- Coverage 65.86% 65.78% -0.08%
==========================================
Files 638 644 +6
Lines 64303 64802 +499
==========================================
+ Hits 42352 42630 +278
- Misses 19577 19781 +204
- Partials 2374 2391 +17
|
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 good overall, but still a few comments
Co-authored-by: Marie Gauthier <marie.gauthier63@gmail.com>
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.
Added a few comments.
Do we want to keep the legacy querier tests around so that we are testing both the v1beta1 and the v1beta2 query server?
Also why do we have this codecov/patch thing? It's quite disruptive to the review process and if we're not actually using it then I'd advocate to remove it.
x/gov/keeper/msg_server.go
Outdated
// Execute the proposal content in a new context branch (with branched store) | ||
// to validate the actual parameter changes before the proposal proceeds | ||
// through the governance process. State is not persisted. | ||
cacheCtx, _ := ctx.CacheContext() |
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.
Don't we eventually want to run writeCache
. Currently this looks like it never actually persists state. Is this intentional?
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 you're right.
So the way it currently works is:
- in EndBlocker, we create a CacheContext
- if all Msgs pass then we write
Which means that in the msg server implementation of ExecLegacyContent, we don't need a CacheContext at all. I removed it.
// Only if it's a MsgExecLegacyContent do we try to execute the | ||
// proposal in a cached context. | ||
// For other Msgs, we do not verify the proposal messages any further. | ||
// They may fail upon execution. | ||
// ref: https://github.com/cosmos/cosmos-sdk/pull/10868#discussion_r784872842 | ||
if msg, ok := msg.(*v1beta2.MsgExecLegacyContent); ok { | ||
cacheCtx, _ := ctx.CacheContext() | ||
if _, err := handler(cacheCtx, msg); err != nil { | ||
return v1beta2.Proposal{}, sdkerrors.Wrap(types.ErrNoProposalHandlerExists, err.Error()) | ||
} | ||
} |
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 no longer need to do this right because we have the new MsgServer method for executing legacy content messages.
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.
this is related to #10868 (comment).
The current code runs the Msg in SubmitProposal iif it's a MsgExecLegacyContent (to match old behavior). We could also remove this code, in which case the legacy content will be run for the 1st time once the proposal passes
I feel that mock running legacy content in SubmitProposal is safe, those old gov handlers are well-known and don't do any side-effects such as sending IBC messages or writing to disk
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.
Ok yeah that's fine with me
Co-authored-by: Callum Waters <cmwaters19@gmail.com>
…s-sdk into callum/gov-msg-server
thanks for the review @cmwaters
You mean this comment #10868 (comment) ? I feel it's one comment per PR, so it doesn't bother me too much, but happy to hear other opinions
Yeah, in this PR I switched |
No I meant the inline comments for every line which doesn't have a test which hits it |
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. I can't actually approve this because I am the author but in any case this seems to ready to merge from my side
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, pending merge conflicts
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. I can't actually approve this because I am the author but in any case this seems to ready to merge from my side
I'll give you mine!
## Description Ref: cosmos#9438 This PR performs the major work of swapping out the v1beta1 msg server and query server for the new one which can process a proposal as an array of messages. This PR still retains the legacy servers which simply wrap around the new ones, providing the same interface as before. In order to keep backwards compatibility, a new msg, `MsgExecLegacyContent` has been created which allows `Content` to become a `Msg` type and still be used as part of the new implementation. --- ### 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... - [ ] included the correct [type prefix](https://github.com/commitizen/conventional-commit-types/blob/v3.0.0/index.json) in the PR title - [ ] added `!` to the type prefix if API or client breaking change - [ ] targeted the correct branch (see [PR Targeting](https://github.com/cosmos/cosmos-sdk/blob/master/CONTRIBUTING.md#pr-targeting)) - [ ] provided a link to the relevant issue or specification - [ ] followed the guidelines for [building modules](https://github.com/cosmos/cosmos-sdk/blob/master/docs/building-modules) - [ ] included the necessary unit and integration [tests](https://github.com/cosmos/cosmos-sdk/blob/master/CONTRIBUTING.md#testing) - [ ] added a changelog entry to `CHANGELOG.md` - [ ] included comments for [documenting Go code](https://blog.golang.org/godoc) - [ ] updated the relevant documentation or specification - [ ] reviewed "Files changed" and left comments if necessary - [ ] confirmed all CI checks have passed ### 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... - [ ] confirmed the correct [type prefix](https://github.com/commitizen/conventional-commit-types/blob/v3.0.0/index.json) in the PR title - [ ] confirmed `!` in the type prefix if API or client breaking change - [ ] confirmed all author checklist items have been addressed - [ ] reviewed state machine logic - [ ] reviewed API design and naming - [ ] reviewed documentation is accurate - [ ] reviewed tests and test coverage - [ ] manually tested (if applicable)
Description
Ref: #9438
This PR performs the major work of swapping out the v1beta1 msg server and query server for the new one which can process a proposal as an array of messages. This PR still retains the legacy servers which simply wrap around the new ones, providing the same interface as before.
In order to keep backwards compatibility, a new msg,
MsgExecLegacyContent
has been created which allowsContent
to become aMsg
type and still be used as part of the new implementation.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