-
Notifications
You must be signed in to change notification settings - Fork 170
refactor: Add RESTful API Serving and refactor client code to support multi-transport #348
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
base: main
Are you sure you want to change the base?
Conversation
# Adding stand-alone support for RESTful API serving Though the RESTful API (JSON+HTTP) can be served from an envoy transcoding of the gRPC service that may not always make sense in all cases. Instead, this PR also adds the ability to serve the RESTful API stand-alone, without needing to also setup the gRPC service. --------- Co-authored-by: Holt Skinner <holtskinner@google.com> Co-authored-by: swapydapy <swapnilag@google.com>
…s and simplify client interfaces (#342) # Description Refactor the client codebase to support automated, configurable, client factory to generate a client based on the agent card details. Adds support for generation of clients based on JSONRPC, gRPC and RESTful interfaces. --------- Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com> Co-authored-by: Holt Skinner <13262395+holtskinner@users.noreply.github.com> Co-authored-by: Holt Skinner <holtskinner@google.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Summary of Changes
Hello @holtskinner, I'm Gemini Code Assist1! 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 significantly refactors the client-side architecture to support multiple communication transports (JSON-RPC, gRPC, and a newly introduced RESTful API) for interacting with agents. It also adds the necessary server-side components to enable agents to serve their functionalities via a RESTful interface. These changes enhance the flexibility and interoperability of the system by allowing clients and agents to negotiate and utilize the most suitable communication protocol.
Highlights
- Multi-Transport Client Refactor: Introduced an abstract
Client
interface and concrete implementations for JSON-RPC, gRPC, and a new RESTful API, enabling flexible communication with agents. The previousA2AClient
is now aliased for backward compatibility. - New Client Factory: Added a
ClientFactory
to dynamically create the appropriate client instance based on the agent's advertised capabilities and the client's configured preferences, simplifying client instantiation and transport negotiation. - RESTful API Serving: Implemented a new RESTful API layer for agents, including
RESTApplication
andA2ARESTFastAPIApplication
, allowing agents to expose their functionalities via standard HTTP/JSON endpoints. This new API leverages Protocol Buffers for data consistency. - Centralized Task Management: Introduced
ClientTaskManager
to standardize the handling and updating ofTask
objects and related events across different client transports, centralizing state management. - Transport Enumeration: A new
Transports
enum has been added to define standard protocol transport labels (GRPC, JSONRPC, RESTful), improving clarity and type safety.
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 in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command>
or @gemini-code-assist <command>
. Below is a summary of the supported commands.
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 issue 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 or fill out our survey to provide feedback.
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
-
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. ↩
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code Review
This pull request introduces multi-transport support for the client, including a new RESTful API implementation. The introduction of a ClientFactory
and a common Client
interface is a great step towards a more maintainable and extensible client library. However, I've identified several critical issues, particularly in the new REST client and server implementations, as well as some regressions and incomplete features in the new transport clients. Please see my detailed comments below.
except ImportError: | ||
# If grpc.aio is not available, define a dummy type for type checking. | ||
# This dummy type will only be used by type checkers. | ||
if TYPE_CHECKING: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
try: | ||
task_id = request.path_params['id'] | ||
history_length = request.query_params.get('historyLength', None) | ||
if historyLength: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
body = await request.body() | ||
params = a2a_pb2.TaskPushNotificationConfig() | ||
Parse(body, params) | ||
params = TaskPushNotificationConfig.model_validate(body) | ||
a2a_request = proto_utils.FromProto.task_push_notification_config( | ||
params, | ||
) | ||
config = ( | ||
await self.request_handler.on_set_task_push_notification_config( | ||
a2a_request, context | ||
) | ||
) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The logic for parsing and validating the request body is incorrect and will fail at runtime.
TaskPushNotificationConfig.model_validate(body)
will raise an error becausebody
is abytes
object, butmodel_validate
expects a dictionary. You should userequest.json()
to get the parsed dictionary.- The subsequent call to
proto_utils.FromProto.task_push_notification_config
is also incorrect as it expects a protobuf message, not a Pydantic model.
Please refactor this to correctly parse the JSON body into the TaskPushNotificationConfig
Pydantic model and pass that to the request handler.
params = TaskPushNotificationConfig.model_validate(await request.json())
config = (
await self.request_handler.on_set_task_push_notification_config(
params, context
)
)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a bug. Shouldn't be using the model validate approach at all, instead line 260 should be deleted
context: ClientCallContext | None = None, | ||
) -> AsyncIterator[Task | Message]: | ||
if not self._config.streaming or not self._card.capabilities.streaming: | ||
raise Exception( | ||
'client and/or server do not support resubscription.' | ||
) | ||
async for event in self._transport_client.resubscribe( | ||
request, | ||
http_kwargs=self.get_http_args(context), | ||
context=context, | ||
): | ||
# Update task, check for errors, etc. | ||
yield event | ||
|
||
async def get_card( | ||
self, | ||
*, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This implementation of resubscribe
appears to be incomplete. It yields raw events from the transport client, but it should process them to yield Task | Message
objects as per the method signature.
The comment # Update task, check for errors, etc.
also suggests this is a work in progress. Please complete this implementation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a valid bug to be fixed
context: ClientCallContext | None = None, | ||
) -> AsyncIterator[Task | Message]: | ||
if not self._config.streaming or not self._card.capabilities.streaming: | ||
raise Exception( | ||
'client and/or server do not support resubscription.' | ||
) | ||
async for event in self._transport_client.resubscribe( | ||
request, | ||
context=context, | ||
): | ||
# Update task, check for errors, etc. | ||
yield event | ||
|
||
async def get_card( | ||
self, | ||
*, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This implementation of resubscribe
appears to be incomplete. It yields raw events from the transport client, but it should likely process them using ClientTaskManager
to yield ClientEvent
or Message
objects, similar to how send_message
is implemented for streaming.
The comment # Update task, check for errors, etc.
also suggests this is a work in progress. Please complete this implementation to ensure consistent behavior across the client.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a valid bug to be fixed
@abstractmethod | ||
async def resubscribe( | ||
self, | ||
request: TaskIdParams, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This abstract method is implemented with yield
, which is inconsistent with other abstract methods in this class that use pass
. This can be confusing for developers implementing this interface.
For consistency, please use pass
here as well. The -> AsyncIterator
type hint is sufficient for type checkers.
pass
This will automatically use the streaming or non-streaming approach | ||
as supported by the server and the client config. Client will | ||
aggregate update events and return an iterator of (`Task`,`Update`) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This abstract method is implemented with yield
, which makes it a concrete method returning an empty async generator. This is inconsistent with other abstract methods in this class (like get_task
) which use pass
.
For consistency and to make it clearer that this method must be implemented by subclasses, please use pass
instead of yield
.
pass
Looks like a merge failure Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
Lock file update with latest dev dependencies
…ad of global installations
…ase variable renaming and module name change for patches
No description provided.