Dev mode gRPC test

[nahguam]

In Dev mode, you are able to test the running gRPC services at http://localhost:8080/q/dev-v1/io.quarkus.quarkus-grpc/services

However, the test link will only be visible for a service if it is deemed to hasTestableMethod. On stepping through the code in GrpcDevConsoleProcessor, this will only be the case if there is a MUTINY_GRPC class for the service available.

In my case I have 2 services - 1 with java code generated by protobuf-maven-plugin and 1 generated by quarkus-maven-plugin. Both services have been implemented using the blocking API but only the one generated by quarkus-maven-plugin is testable.

1. Is there a specific reason that only mutiny generated service classes are testable?
2. Is it a bug or intended that even though there is a mutiny class available, the @GrpcService implementation is blocking (extends FooGrpc.FooGrpcImplBase) but is still deemed testable?

Side question: is this UI planned to be available under the v2 dev UI?

[quarkus-bot[bot]]

/cc @alesj (grpc), @cescoffier (grpc)

[cescoffier]

gRPC testability is tricky as gRPC stubs are in general final classes, which cannot be proxied. So, for mutiny we workaround that problem. We cannot in the general case.

About 2) I'm not sure I understand. The service implementation and how it's consumed are unrelated. One can be blocking while the other one reactive.

About the side question, yes, we want to do it... It's just taking time (and does not have a high priority, unfortunately).

[nahguam]

Thanks for the quick reply 👍 I'm just trying to piece things together.

By the workaround do you mean GrpcDevConsoleWebSocketListener.init()? In there I see it creates client stubs from the standard generated classes not the mutiny generated classes.

In my original question I had assumed that it was the server implementation type that was important. From your answer I gather that it's the client side that matters. However it looks like only the standard newStub method on the default java implementation is used. No mutiny classes at all. But GrpcDevConsoleProcessor.getGrpcServices() method only includes services as candidates for testing that have mutiny generated code.

I think I'm still missing a piece of the context?

[cescoffier]

The GrpcDevConsoleProcessor does not do anything during the tests.
During the tests, it's regular gRPC between a client and a server.