Skip to content
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

Merged
merged 38 commits into from
Feb 18, 2021
Merged

Use service Msgs in CLI tx commands #8512

merged 38 commits into from
Feb 18, 2021

Conversation

amaury1093
Copy link
Contributor

@amaury1093 amaury1093 commented Feb 4, 2021

Description

closes: #8306
closes #8346

Some stuff came up when converting to Service Msgs:


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.

  • Targeted PR against correct branch (see CONTRIBUTING.md)
  • Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
  • Code follows the module structure standards.
  • Wrote unit and integration tests
  • Updated relevant documentation (docs/) or specification (x/<module>/spec/)
  • Added relevant godoc comments.
  • Added a relevant changelog entry to the Unreleased section in CHANGELOG.md
  • Re-reviewed Files changed in the Github PR explorer
  • Review Codecov Report in the comment section below once CI passes

Comment on lines 273 to 279
// 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.
Copy link
Contributor Author

@amaury1093 amaury1093 Feb 9, 2021

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
Copy link

codecov bot commented Feb 11, 2021

Codecov Report

Merging #8512 (3b1ab58) into master (53637b6) will increase coverage by 0.00%.
The diff coverage is 45.41%.

Impacted file tree graph

@@           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     
Impacted Files Coverage Δ
types/service_msg.go 0.00% <0.00%> (ø)
x/auth/legacy/legacytx/stdsign.go 82.97% <ø> (ø)
x/gov/types/msgs.go 47.11% <ø> (ø)
x/params/client/cli/tx.go 0.00% <0.00%> (ø)
x/staking/client/rest/query.go 40.66% <0.00%> (-1.21%) ⬇️
x/staking/types/msg.go 23.92% <ø> (ø)
x/gov/client/utils/query.go 25.72% <25.40%> (-2.15%) ⬇️
x/staking/client/cli/tx.go 60.64% <77.77%> (+1.43%) ⬆️
x/auth/vesting/client/cli/tx.go 57.14% <80.00%> (+3.29%) ⬆️
x/bank/client/cli/tx.go 50.00% <80.00%> (+5.17%) ⬆️
... and 8 more

@amaury1093 amaury1093 marked this pull request as ready for review February 11, 2021 14:40
Copy link
Contributor

@atheeshp atheeshp left a 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

x/auth/legacy/legacytx/stdsign.go Outdated Show resolved Hide resolved
client/tx/legacy_test.go Outdated Show resolved Hide resolved
@clevinson clevinson self-assigned this Feb 17, 2021
Copy link
Contributor

@clevinson clevinson left a 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.

client/tx/legacy_test.go Outdated Show resolved Hide resolved
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() {
Copy link
Contributor

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?

Copy link
Contributor Author

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 {
Copy link
Contributor

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)

Copy link
Contributor Author

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.

x/staking/types/msg.go Show resolved Hide resolved
@@ -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"
Copy link
Contributor

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..

Copy link
Contributor Author

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.

// we just call GetSignBytes on it.
svcMsg, ok := msg.(sdk.ServiceMsg)
if ok {
msgBytes = svcMsg.Request.(sdk.Msg).GetSignBytes()
Copy link
Member

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

Copy link
Member

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?

Copy link
Contributor Author

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done in bad79a5

@amaury1093 amaury1093 added the A:automerge Automatically merge PR once all prerequisites pass. label Feb 18, 2021
@mergify mergify bot merged commit 73e38e4 into master Feb 18, 2021
@mergify mergify bot deleted the am-8306-svcmsg-cli branch February 18, 2021 18:00
@amaury1093 amaury1093 mentioned this pull request Mar 3, 2021
9 tasks
@amaury1093 amaury1093 mentioned this pull request Apr 30, 2021
9 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A:automerge Automatically merge PR once all prerequisites pass. C:CLI
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Allow service Msg's to gracefully support Amino JSON CLI tx commands should generate service Msgs
6 participants