You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
IBC interchain accounts supported a ModuleQuerySafe handler for use in ibc from v8.3.0 (see: cosmos/ibc-go#5784).
Upgrading to v0.52 has an API breakage when using Environment.QueryRouterService in favour of baesapp's GRPCQueryRouter.
The API has changed from having grpc service path and data (bytes) to accepting a generalised proto.Message interface via Invoke(ctx, msg).
I have attempted to migrate the ibc code to using the proto resolver and reflect methods. This doesn't work with the following implementation: cosmos/ibc-go@8d114c6
From protobuf docs the recommended way seems to be to use dynamicpb.Message.
test panicked: interface conversion: *types.QueryBalanceResponse is not protoreflect.ProtoMessage: missing method ProtoReflect
Ideally we can support a clean migration path for this handler as its being used cross chain and having to rely on a new API would cause fragmentation and some compatibility issues.
Cosmos SDK Version
0.52
How to reproduce?
Checkout the commit in ibc-go linked above and run make test. Or go test 27-interchain-accounts/host pkg directly.
The text was updated successfully, but these errors were encountered:
This is because to make invokation fast we do not encode and decode messages (for better or for worse); Although we could add a method to use the bytes representation.
So to implement this use case you can do the following, assuming you have a message name eg: "cosmso.bank.v1beta1.MsgSend"
funcforgeProtoTypeFromName(msgNamestring) (proto.Message, error) {
typ:=gogoproto.MessageType(msgName)
iftyp==nil {
returnnil, fmt.Errorf("no message type found for %s", msgName)
}
msg, ok:=reflect.New(typ.Elem()).Interface().(gogoproto.Message)
if!ok {
returnnil, fmt.Errorf("could not create response message %s", msgName)
}
}
This can be used in place of dynamicpb to generate a message dynamically which is the concrete type of the handler, should also be generally faster than dynamicpb (and old baseapp way of doing things) since it does not need multiple encodings.
Is there an existing issue for this?
What happened?
IBC interchain accounts supported a
ModuleQuerySafe
handler for use in ibc from v8.3.0 (see: cosmos/ibc-go#5784).Upgrading to v0.52 has an API breakage when using
Environment.QueryRouterService
in favour of baesapp'sGRPCQueryRouter
.The API has changed from having grpc service path and data (bytes) to accepting a generalised
proto.Message
interface viaInvoke(ctx, msg)
.I have attempted to migrate the ibc code to using the proto resolver and reflect methods. This doesn't work with the following implementation: cosmos/ibc-go@8d114c6
From protobuf docs the recommended way seems to be to use
dynamicpb.Message
.Using the
dynamicpb.Message
will route to the correct handler and get a "successful" msg response but then it explodes/panics herehttps://github.com/cosmos/cosmos-sdk/blob/main/baseapp/internal/protocompat/protocompat.go#L167 with
Ideally we can support a clean migration path for this handler as its being used cross chain and having to rely on a new API would cause fragmentation and some compatibility issues.
Cosmos SDK Version
0.52
How to reproduce?
Checkout the commit in ibc-go linked above and run make test. Or
go test
27-interchain-accounts/host pkg directly.The text was updated successfully, but these errors were encountered: