-
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
Use service Msgs in CLI tx commands #8512
Conversation
x/gov/client/utils/query.go
Outdated
// searchEvents queries txs by events with both `oldMsgType` and `newMsgtype`, | ||
// merges the results into one *sdk.SearchTxsResult. | ||
func searchEvents(clientCtx client.Context, oldMsgType, newMsgType string, otherEvents ...string) (*sdk.SearchTxsResult, error) { | ||
// Tx are indexed in tendermint via their Msgs `Type()`, which can be: | ||
// - via legacy Msgs (amino or proto), their `Type()` is a custom string, | ||
// - via ADR-031 service msgs, their `Type()` is the protobuf FQ method name. | ||
// In searching for events, we search for both `Type()`s. |
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 a bugfix that got uncovered when converting CLI to service Msgs.
Before:
We only had amino Msgs, their Type()
was e.g. "submit_proposal"
. So when searching txs, we were searching message.action='submit_proposal'
Now (since 0.40):
We have amino Msgs, proto Msgs (Type()
is same as amino), and service Msgs (Type()
is proto FQ method name). So for searching txs we need to search for both old and new Type()
s. I'm doing 2 separate searches:
message.action='submit_proposal'
// then
message.action='/cosmos.gov.v1beta1.Msg/SubmitProposal'
and merging the tx responses.
Codecov Report
@@ Coverage Diff @@
## master #8512 +/- ##
========================================
Coverage 61.42% 61.43%
========================================
Files 658 658
Lines 37627 37768 +141
========================================
+ Hits 23111 23201 +90
- Misses 12104 12143 +39
- Partials 2412 2424 +12
|
…dk into am-8306-svcmsg-cli
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, Can you resolve conflicts
Co-authored-by: atheeshp <[email protected]>
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.
Nice one! Generally looks good. I have a few clarifying Q's / smaller nits.
I've gone through everything except the details of the event querying logic (e.g. x/gov/client/utils/query.go
). Will finish looking at that and wrap up my review tomorrow.
x/bank/client/cli/cli_test.go
Outdated
func (s *IntegrationTestSuite) TestBankMsgService() { | ||
// TestLegacyProtoMsgSend uses the legacy proto MsgSend CLI util to make sure | ||
// legacy proto Msgs are still handled. The real CLI commands use service Msgs. | ||
func (s *IntegrationTestSuite) TestLegacyProtoMsgSend() { |
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.
What's the reason for keeping these tests? What pathways for legacy proto msg's still exist?
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.
What pathways for legacy proto msg's still exist?
We can send proto msgs via GRPC, REST and the TM broadcast endpoint. But all of these are already tested in other parts of the codebase, so I guess this fictive "send proto msgs via CLI" can be removed. I also refactored a bit the code in 015aef2.
@@ -49,11 +50,14 @@ func NewMsgVerifyInvariantTxCmd() *cobra.Command { | |||
senderAddr := clientCtx.GetFromAddress() | |||
|
|||
msg := types.NewMsgVerifyInvariant(senderAddr, moduleName, route) | |||
if err := msg.ValidateBasic(); err != nil { |
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.
General question for all of these - does ValidateBasic()
get called under the hood still somewhere in the new service msg path? Where does that happen? (was having trouble finding)
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, when using service msg clients, the ServiceMsgClientConn.Invoke
method is called, and it does a ValidateBasic.
@@ -18,6 +18,12 @@ const ( | |||
TypeMsgVote = "vote" | |||
TypeMsgVoteWeighted = "weighted_vote" | |||
TypeMsgSubmitProposal = "submit_proposal" | |||
|
|||
// These are used for querying events by action. | |||
TypeSvcMsgDeposit = "/cosmos.gov.v1beta1.Msg/Deposit" |
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.
Same comment as bellow - are these FQ paths not defined elsehwere already? It feels like this is will be a very easy thing to forget to update when we migrate out of beta, change packages, etc. Yes this shouldn't happen often... but when it does, I worry these const strings may get left behind..
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.
Unfortunately not... In Aaron's custom code generator they are, and i think that's useful.
x/auth/legacy/legacytx/stdsign.go
Outdated
// we just call GetSignBytes on it. | ||
svcMsg, ok := msg.(sdk.ServiceMsg) | ||
if ok { | ||
msgBytes = svcMsg.Request.(sdk.Msg).GetSignBytes() |
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 cast can fail, we should check
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.
Also we should just implement this on ServiceMsg.GetSignBytes rather than panicking there, 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.
yeah, I guess that would work too, and we wouldn't need any additional code here
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.
done in bad79a5
Description
closes: #8306
closes #8346
Some stuff came up when converting to Service Msgs:
x/gov/client/utils/query.go
. These utils used to search only for txs with legacy Msgs. Now I added support for searching for legacy Msgs and service Msgs. See Use service Msgs in CLI tx commands #8512 (comment)Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.
docs/
) or specification (x/<module>/spec/
)godoc
comments.Unreleased
section inCHANGELOG.md
Files changed
in the Github PR explorerCodecov Report
in the comment section below once CI passes