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

Python asyncio servicer context invocation_metadata returns a tuple instead of Metadata #36613

Closed
artificial-aidan opened this issue May 14, 2024 · 6 comments

Comments

@artificial-aidan
Copy link

What version of gRPC and what language are you using?

Python 3.11 grpcio 1.63.0

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

OSX 10.14

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

3.11

What did you do?

Created a python asyncio server. Called invocation_metadata and had a tuple returned

    async def UnaryUnary(self, request: Request, context: grpc.aio.ServicerContext) -> Response:  # noqa: N802
        md = context.invocation_metadata()
        if isinstance(md, grpc.aio.Metadata):
            print('hello')
        type(md) # returns tuple

What did you expect to see?

invocation_metadata to return a grpc.aio.Metadata object like the type hint suggests

@gnossen
Copy link
Contributor

gnossen commented May 16, 2024

Thanks for pointing this out! This does indeed seem to be an unintentional discrepancy. In order to minimize the impact of a fix here, I think the right thing to do is to change the type to match the implementation rather than the other way around.

@artificial-aidan
Copy link
Author

That's definitely a bit of a bummer. But makes sense. It would be quite the breaking change to change the return type. Is there any precedence for adding a differently named method that returns metadata, or as a fuction parameter.

@gnossen
Copy link
Contributor

gnossen commented May 16, 2024

No precedent, but it's definitely something that could be discussed. We verbally discussed something like invocation_metadata2 when reviewing this issue. Though adding a whole new method would be a bit of a bigger effort (gRFC, implementation, testing, and documentation). I think we'd need someone to volunteer to pitch in to make something like that happen.

@artificial-aidan
Copy link
Author

Its a lot of effort for something that can be fixed with a one-liner turning it into metadata again.

I think fixing the typing would solve 90% of the problem

@iamWing
Copy link

iamWing commented May 29, 2024

Was about to report this issue as well. Yes I agree with @gnossen that I wouldn't want to see a fix that changes the return type, as it'd break the current code base I have (which I do dict(context.invocation_metadata()) to convert it to a dictionary to allow me using the .get function for getting a specific metadata). Something like invocation_metadata2 would be welcome as it means that I can gradually migrate to the new function instead of having to deal with the breaking change all at once.

@sreenithi sreenithi assigned sreenithi and unassigned sourabhsinghs Jun 4, 2024
copybara-service bot pushed a commit that referenced this issue Jun 21, 2024
Updated the type hint for return type of grpc.aio.ServicerContext.invocation_metadata() to Optional[MetadataType] instead of Optional[Metadata].

MetadataType is already defined to be a Sequence[MetadatumType] and hence the type hint will reflect the sequence being returned, hence solving the [user's reported issue](#36613)

Closes #36894

COPYBARA_INTEGRATE_REVIEW=#36894 from sreenithi:fix-issues/36613 7d3a047
PiperOrigin-RevId: 645276778
@sreenithi
Copy link
Contributor

the above PR should have updated the invocation_metadata() return type. Hence closing the issue

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants