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

[Bug]: Incompatible migration path for QueryRouterService #22833

Closed
1 task done
damiannolan opened this issue Dec 11, 2024 · 3 comments
Closed
1 task done

[Bug]: Incompatible migration path for QueryRouterService #22833

damiannolan opened this issue Dec 11, 2024 · 3 comments
Assignees
Labels

Comments

@damiannolan
Copy link
Contributor

Is there an existing issue for this?

  • I have searched the existing issues

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

Using the dynamicpb.Message will route to the correct handler and get a "successful" msg response but then it explodes/panics here
https://github.com/cosmos/cosmos-sdk/blob/main/baseapp/internal/protocompat/protocompat.go#L167 with

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.

@damiannolan
Copy link
Contributor Author

For now I will continue using baseapp.GRPCQueryRouter

@testinginprod
Copy link
Contributor

Hello

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"

func forgeProtoTypeFromName(msgName string) (proto.Message, error) {
    typ := gogoproto.MessageType(msgName)
	if typ == nil {
		return nil, fmt.Errorf("no message type found for %s", msgName)
	}
	msg, ok := reflect.New(typ.Elem()).Interface().(gogoproto.Message)
	if !ok {
		return nil, 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.

@damiannolan
Copy link
Contributor Author

ACK! Applied chad fix here cosmos/ibc-go@151c0cb and have passing tests now.

Thanks a bunch!

@github-project-automation github-project-automation bot moved this from 📋 Backlog to 🥳 Done in Cosmos-SDK Dec 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Status: 🥳 Done
Development

No branches or pull requests

4 participants