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

Extend ClientConn on TxBuilder #7630

Closed
wants to merge 26 commits into from
Closed

Extend ClientConn on TxBuilder #7630

wants to merge 26 commits into from

Conversation

amaury1093
Copy link
Contributor

@amaury1093 amaury1093 commented Oct 22, 2020

Description

ref: #7541

This PR introduces a clunky UX to manage service Msgs with TxBuilder, see #7630 (comment). It should be ultimately replaces by a custom code generator #8270.

  • Update x/bank/cli/cli_test.go

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

@codecov
Copy link

codecov bot commented Oct 22, 2020

Codecov Report

Merging #7630 (7afe557) into master (6fb5e1f) will decrease coverage by 0.04%.
The diff coverage is 0.00%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master    #7630      +/-   ##
==========================================
- Coverage   61.82%   61.77%   -0.05%     
==========================================
  Files         609      611       +2     
  Lines       35110    35136      +26     
==========================================
  Hits        21707    21707              
- Misses      11121    11147      +26     
  Partials     2282     2282              
Impacted Files Coverage Δ
x/auth/legacy/legacytx/msg_service.go 0.00% <0.00%> (ø)
x/auth/tx/builder.go 74.80% <ø> (ø)
x/auth/tx/msg_service.go 0.00% <0.00%> (ø)

@@ -34,6 +36,7 @@ type (
// signatures, and provide canonical bytes to sign over. The transaction must
// also know how to encode itself.
TxBuilder interface {
gogogrpc.ClientConn
Copy link
Contributor Author

Choose a reason for hiding this comment

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

I don't think an update to ADR 020 is really needed, wdyt?

Copy link
Member

Choose a reason for hiding this comment

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

Probably not. But just wondering is it better to change the interface, or create a separate struct that implements ClientConn wraps TxBuilder?

Copy link
Collaborator

Choose a reason for hiding this comment

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

I like the idea of creating ClientConn. I was confused with the Invoke method initially. Maybe we can call the new interface: MsgSrvClient?

Copy link
Collaborator

Choose a reason for hiding this comment

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

Ping?

Copy link
Contributor Author

@amaury1093 amaury1093 Dec 15, 2020

Choose a reason for hiding this comment

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

I'm not sure here. Are you proposing:

type MsgSrvClient struct {
  txBuilder TxBuilder
}

var _ gogogrpc.ClientConn = MsgSrvClient{}

? I feel yet another struct creates more confusion. At some point we should revisit #7630 (comment), which imo is the ideal way forward.

@amaury1093 amaury1093 marked this pull request as ready for review October 23, 2020 12:36
codec/types/any.go Outdated Show resolved Hide resolved
Co-authored-by: Alessio Treglia <[email protected]>
Copy link
Contributor

@alessio alessio left a comment

Choose a reason for hiding this comment

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

ACK

Copy link
Member

@aaronc aaronc left a comment

Choose a reason for hiding this comment

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

The unfortunate part of this is that it only allows setting one Msg. We should add another function AppendMsg to TxBuilder and use that instead so that multiple Msgs can be added.

@amaury1093
Copy link
Contributor Author

Ah, you're right. I added AppendMsgs. Then I realized that method makes SetMsgs kind of useless, so I removed SetMsgs in my last commit.

codec/types/any.go Outdated Show resolved Hide resolved
// Ex:
// This will allow us to pack service methods in Any's using the full method name
// as the type URL and the request body as the value.
func NewAnyWithTypeURL(typeURL string, value proto.Message) (*Any, error) {
Copy link
Collaborator

Choose a reason for hiding this comment

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

This function looks dangerous.

Is the protobuf generated code already providing it? Maybe there is a method already for this?

Copy link
Contributor Author

@amaury1093 amaury1093 Oct 26, 2020

Choose a reason for hiding this comment

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

Is the protobuf generated code already providing it? Maybe there is a method already for this?

I don't think so, because we have our own implementation of Any.

codec/types/any.go Outdated Show resolved Hide resolved
x/auth/tx/msg_service.go Outdated Show resolved Hide resolved
x/auth/legacy/legacytx/msg_service.go Outdated Show resolved Hide resolved
x/auth/tx/msg_service.go Show resolved Hide resolved
x/auth/legacy/legacytx/msg_service.go Show resolved Hide resolved
client/tx_config.go Outdated Show resolved Hide resolved
@@ -34,6 +36,7 @@ type (
// signatures, and provide canonical bytes to sign over. The transaction must
// also know how to encode itself.
TxBuilder interface {
gogogrpc.ClientConn
Copy link
Member

Choose a reason for hiding this comment

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

Probably not. But just wondering is it better to change the interface, or create a separate struct that implements ClientConn wraps TxBuilder?

@aaronc
Copy link
Member

aaronc commented Oct 26, 2020

@amaurymartiny I would say let's hold off on merging this until we're done with 0.40 backport issues. What do you think?

@amaury1093
Copy link
Contributor Author

amaury1093 commented Oct 26, 2020

@amaurymartiny I would say let's hold off on merging this until we're done with 0.40 backport issues. What do you think?

Ah ok. I kind of wanted to get this in to have the tests i write for #7647 using this already, not strictly necessary but slightly cleaner imo to avoid having this in other tests.

@aaronc
Copy link
Member

aaronc commented Oct 26, 2020

@amaurymartiny I would say let's hold off on merging this until we're done with 0.40 backport issues. What do you think?

Ah ok. I kind of wanted to get this in to have the tests i write for #7647 using this already, not strictly necessary but slightly cleaner imo to avoid having this in other tests.

Ah okay, well let's not remove SetMsgs then

@amaury1093
Copy link
Contributor Author

amaury1093 commented Oct 26, 2020

Actually no, I may have found a way not to DRY in #7647. Would also like to revisit:

Probably not. But just wondering is it better to change the interface, or create a separate struct that implements ClientConn wraps TxBuilder?

as it still feels a bit weird to write:

bankMsgClient := types.NewMsgClient(txBuilder)
_, err = bankMsgClient.Send(context.Background(), msg) // seems like we're actually sending. `context.Background()` is also useless.

we can probably build a wrapper somewhere to hide the awkwardness.

Putting to draft for now.

@amaury1093 amaury1093 marked this pull request as draft October 26, 2020 15:04
@aaronc
Copy link
Member

aaronc commented Oct 29, 2020

as it still feels a bit weird to write:

bankMsgClient := types.NewMsgClient(txBuilder)
_, err = bankMsgClient.Send(context.Background(), msg) // seems like we're actually sending. `context.Background()` is also useless.

I think we're going to want to do custom code generation for this eventually. The grpc code generator isn't that complex and protobuf recommends people write their own code generation plugins anyway. Ideally we just something that takes into account that the call is async and maybe even that we're using client.Context instead of context.Context (or don't even need a context). Anyway, I think this is fine for now but just thoughts for the future.

@@ -19,6 +19,11 @@ func (w *wrapper) Invoke(_ gocontext.Context, method string, args, reply interfa
return sdkerrors.Wrapf(sdkerrors.ErrInvalidType, "%T should implement %T", args, (*sdk.MsgRequest)(nil))
}

err := req.ValidateBasic()
if err != nil {
return err
Copy link
Contributor

Choose a reason for hiding this comment

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

shouldn't we use sdkerrors.Wrapf here?

Copy link
Contributor Author

@amaury1093 amaury1093 Dec 15, 2020

Choose a reason for hiding this comment

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

I thumbed up, but maybe it's not necessary. err should already be a SDK error. I used sdkerrors.Wrapf 3 lines above because there's no underlying error.

@amaury1093 amaury1093 marked this pull request as ready for review December 15, 2020 17:15
@amaury1093 amaury1093 mentioned this pull request Jan 11, 2021
9 tasks
Comment on lines +13 to +16
// Invoke implements the grpc ClientConn.Invoke method. This is so that we can
// use ADR-031 service `Msg`s with StdTxBuilder. Invoking this method will
// **append** the service Msg into the TxBuilder's Msgs array.
// TODO Full amino support still needs to be added as part of https://github.com/cosmos/cosmos-sdk/issues/7541.
Copy link
Contributor Author

@amaury1093 amaury1093 Jan 11, 2021

Choose a reason for hiding this comment

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

This PR was originally set up in #7541. It introduces a clunky UX to manage service Msgs with TxBuilder, see #7630 (comment). It should be ultimately replaced by a custom code generator #8270.

However, as I understand, #8270 is targetted for 0.42, whereas this PR might be useful for 0.41's x/fee_grant and x/authz (see #8061 (comment), #7629 (comment), both use a temporary ServiceMsgClientConn struct for now).

Should we:

  1. Merge this, and have a slightly clunky txBuilder for now?
  2. Close this, use temporary ServiceMsgClientConn wherever we need service Msgs, and wait for Custom protobuf service code generator #8270?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Talking offline with the Regen team, I'll close this PR.

@amaury1093 amaury1093 closed this Jan 11, 2021
@amaury1093 amaury1093 deleted the am-7541-txbuilder branch January 11, 2021 15:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants