feat: Add an optional tenant parameter to the getExtendedAgentCard operation

[jmesnil]

Fixes #608 🦕

[gemini-code-assist]

Summary of Changes

Hello @jmesnil, 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 an optional tenant parameter to the getExtendedAgentCard operation, enabling multi-tenancy support for this functionality. The changes involve updating method signatures, creating a dedicated parameter object, and integrating this new parameter into the GRPC, JSONRPC, and REST client transport mechanisms. This enhancement allows clients to specify a tenant when requesting an agent card, facilitating more flexible and tenant-aware operations.

Highlights

• New Parameter Object: A new record, GetExtendedAgentCardParams, has been introduced to encapsulate the optional tenant parameter for the getExtendedAgentCard operation, providing a structured way to pass request parameters.
• API Signature Update: The getExtendedAgentCard method signature has been updated across AbstractClient, ClientTransport, and Client implementations to accept the new GetExtendedAgentCardParams object, along with new overloads in AbstractClient for backward compatibility and convenience.
• Transport Layer Integration: The GRPC, JSONRPC, and REST transport layers have been modified to correctly process and forward the optional tenant parameter when retrieving the extended agent card, ensuring multi-tenancy support at the communication level.
• Test Coverage and Refinements: Existing test cases have been updated to reflect the new API signature, and several unused imports were removed across various files, improving code cleanliness.

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
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

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 introduces an optional tenant parameter to the getExtendedAgentCard operation, addressing issue #608. The changes involve creating a new GetExtendedAgentCardParams record, updating the ClientTransport interface, modifying AbstractClient with new overloads, and updating the implementations in Client, GrpcTransport, JSONRPCTransport, and RestTransport to handle the new parameter. The ProtoUtils class was also updated for gRPC mapping, and a test case was adjusted. Overall, the implementation is correct and aligns with the feature request. The Javadoc comments provided address minor formatting and consistency issues.

[jmesnil]

@kabir @ehsavoie I've followed the same patterns than the other operations to take into account the optional tenant parameter.
However, I'm not sure if what we have for gRPC is correct.
For JsonRPC & REST, we append the tenant to the URL before sending the HTTP request.
For gRPC, we do nothing? From the protobuf, it seems that we should change the name of the operation (eg https://github.com/a2aproject/A2A/blob/92e6fb712ebeddd732a0a124b95d5ff8db4e0d41/specification/grpc/a2a.proto#L121) but I'm not sure were to do that...

[ehsavoie]

@jmesnil afaik for grpc the tenant is a parameter https://github.com/a2aproject/A2A/blob/92e6fb712ebeddd732a0a124b95d5ff8db4e0d41/specification/grpc/a2a.proto#L849

[jmesnil]

ok I see. For gRPC, tenant is just a parameter (as opposed to JSON-RPC & REST where the tenant is put into the endpoint URL).
Then it's up to the server implementation to support it.... Which is maybe something to bring to the spec? Can a server ignore the "tenant" parameter? Should the capabilities of the agent card specify that it supports multitenancy?

[jmesnil]

/gemini review

[gemini-code-assist]

Code Review

The pull request successfully adds an optional tenant parameter to the getExtendedAgentCard operation across the client and transport layers. The changes introduce new overloaded methods in AbstractClient and Client for convenience, and update the ClientTransport interface and its implementations (GrpcTransport, JSONRPCTransport, RestTransport) to propagate and utilize this new parameter. A new record GetExtendedAgentCardParams is also introduced to encapsulate the parameters for this operation. There is a maintainability concern regarding the JSONRPCTransport and RestTransport implementations, as they unnecessarily depend on gRPC-specific types, which should be addressed to improve modularity and separation of concerns.