-
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
Extend ClientConn on TxBuilder #7630
Conversation
Codecov Report
@@ 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
|
@@ -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 |
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 don't think an update to ADR 020 is really needed, wdyt?
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.
Probably not. But just wondering is it better to change the interface, or create a separate struct that implements ClientConn wraps TxBuilder?
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 like the idea of creating ClientConn. I was confused with the Invoke
method initially. Maybe we can call the new interface: MsgSrvClient
?
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.
Ping?
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'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.
Co-authored-by: Alessio Treglia <[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.
ACK
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.
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 Msg
s can be added.
Ah, you're right. I added |
codec/types/any.go
Outdated
// 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) { |
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 function looks dangerous.
Is the protobuf generated code already providing it? Maybe there is a method already for this?
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 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.
@@ -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 |
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.
Probably not. But just wondering is it better to change the interface, or create a separate struct that implements ClientConn wraps TxBuilder?
@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 |
Actually no, I may have found a way not to DRY in #7647. Would also like to revisit:
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. |
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 |
@@ -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 |
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.
shouldn't we use sdkerrors.Wrapf
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.
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.
// 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. |
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 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:
- Merge this, and have a slightly clunky txBuilder for now?
- Close this, use temporary
ServiceMsgClientConn
wherever we need service Msgs, and wait for Custom protobuf service code generator #8270?
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.
Talking offline with the Regen team, I'll close this PR.
TxBuilder
won't be able to handle service Msgs (until Custom protobuf service code generator #8270)- If we want to use service msgs, we use the temporary ServiceMsgClientConn.
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.
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.
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