What version of gRPC and what language are you using?

Python 1.48.1

What operating system (Linux, Windows,...) and version?

macOS 12.2.1 + ubuntu 20.0

What runtime / compiler are you using (e.g. python version or version of gcc)

Python 3.8, 3.9, 3.10

What did you do?

Retrieved the client_call_details.method value in a grpc.aio client interceptor

class FailingInterceptor(grpc.aio.UnaryUnaryClientInterceptor):
    async def intercept_unary_unary(
        self, continuation, client_call_details, request
    ):
        assert isinstance(client_call_details.method, str), "This fails, but shouldn't"
        return await continuation(client_call_details, request)

What did you expect to see?

client_call_details.method to be a string, in accordance with its type definition. (code, docs)

What did you see instead?

The type of client_call_details.method is bytes so you need to call .decode() on it to get a usable string.

The type mismatch seems to be introduced in the __invoke__ methods of InterceptedUnaryUnaryCall, InterceptedUnaryStreamCall, InterceptedStreamUnaryCall, and InterceptedStreamStreamCall. All of them take a method: bytes and pass it, unchanged, to grpc.aio.ClientCallDetails.

For InterceptedUnaryUnaryCall: __invoke__ definition with method as bytes, and method being passed on to ClientCallDetails..

Anything else we should know about your project / environment?

I found this while trying to implement grpc.aio support within open-telemetry/opentelemetry-python-contrib. I guess the fix is to just call .decode() on method before passing it to ClientCallDetails but that seems like it would be a "breaking fix" if other people are relying on the behaviour of it being bytes. Happy to put a PR in if you can advise how to approach it given this may be a breaking change in some usages.