feat: ServerCallContext ports from Python implementation

[kabir]

Port server-side extension support and implement complete gRPC context access equivalent to Python's ServicerContext. Adds client/server metadata support, rich context information, and interceptor infrastructure while maintaining backward compatibility.

[gemini-code-assist]

Summary of Changes

Hello @kabir, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request introduces comprehensive server-side extension support and enriches the gRPC ServerCallContext to align with the capabilities of Python's ServicerContext. It establishes a robust mechanism for clients to request extensions via a standardized header and for servers to process and manage these extensions, ensuring backward compatibility while providing a more powerful and flexible context for handling requests.

Highlights

• Enhanced gRPC ServerCallContext: The ServerCallContext has been significantly enhanced to provide richer context information for gRPC server-side calls, mirroring the functionality of Python's ServicerContext. This includes access to full gRPC metadata, method name, and peer information.
• Server-Side Extension Support: A new A2AExtensionsInterceptor has been introduced for gRPC servers. This interceptor captures the X-A2A-Extensions header from incoming requests and makes the requested extensions available within the ServerCallContext.
• Client-Side Extension Header Propagation: The GrpcTransport on the client side now attaches the X-A2A-Extensions header from the ClientCallContext to outgoing gRPC requests, ensuring that server-side extensions can be properly requested and processed.
• Unified Extension Handling: A new A2AHeaders class defines common header constants, and an A2AExtensions utility class provides methods for parsing and managing requested extensions across different transport layers (gRPC, JSON-RPC, REST).
• ServerCallContext Extension Management: The ServerCallContext now includes dedicated fields and methods to manage both requestedExtensions (from the client) and activatedExtensions (by the server application), allowing for dynamic extension activation.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request successfully ports server-side extension support from the Python implementation, introducing a gRPC interceptor to enrich the ServerCallContext with metadata, peer information, and method details, thereby achieving feature parity with Python's ServicerContext. The changes are well-implemented across the gRPC, JSON-RPC, and REST transports, including necessary modifications to ServerCallContext and the addition of comprehensive unit tests. My review includes one suggestion to refactor duplicated code in GrpcHandler for improved maintainability.

[fjuma]

This annotation can be removed right?

[kabir]

Thanks @fjuma. I've rebased and addressed the comments

[fjuma]

Was just thinking some more about this and realized that I can probably modify #292 to add the authorization/api-key headers for gRPC in a similar way.

Currently, we are relying on the user configuring a gRPC ClientInterceptor to specify the token/API key. Instead, I think I can update GrpcTransport to make use of the ClientCallInterceptors so that the AuthInterceptor could be used for gRPC like we use it for the other transports to add the appropriate header. And then, I can update this method to add the appropriate header to the gRPC metadata if present.