feat: implement tasks/list RPC

[birdayz]

What

Wire the tasks/list method through all protocol layers: JSON-RPC client/server, gRPC client, proto conversion, transport interface, request handler, and intercepted handler.

Why

The TSC voted to add tasks/list with filtering and pagination to the spec for 0.4.0. The task store already implements List() with all the filtering logic (context ID, status, last updated time, pagination, history length, artifacts). This was just never exposed through the protocol.

Implementation details

Pure plumbing - no new business logic. Each layer gets the obvious ListTasks method that delegates to the next:

• Transport interface + unimplementedTransport stub
• JSON-RPC client: sends tasks/list, unmarshals ListTasksResponse
• JSON-RPC server: dispatches tasks/list to onListTasks
• gRPC client: converts via pbconv, calls proto ListTasks
• RequestHandler interface + default impl delegates to taskStore.List()
• InterceptedHandler: wraps with before/after interceptors
• MethodTasksList constant added

References

re #58
Spec PR: a2aproject/A2A#831

[gemini-code-assist]

Summary of Changes

Hello @birdayz, 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 the tasks/list RPC method, enabling clients to retrieve tasks with advanced filtering and pagination capabilities. The changes primarily involve integrating this new method across the entire communication stack, from client-side interfaces to server-side handlers and protocol conversions, ensuring the existing robust task listing logic is now accessible via the protocol.

Highlights

• New RPC Method: Implemented the tasks/list RPC method, which was voted into the spec for 0.4.0, to allow filtering and pagination of tasks.
• Protocol Layer Integration: The tasks/list method has been wired through all necessary protocol layers, including JSON-RPC client/server, gRPC client, proto conversion, transport interface, request handler, and intercepted handler.
• Plumbing, Not Business Logic: This pull request focuses purely on plumbing, exposing existing task store List() functionality without introducing new business logic.

Changelog

• a2aclient/client.go
  • Added ListTasks method to the Client struct, including interceptBefore and interceptAfter calls.
• a2aclient/client_test.go
  • Added ListTasksFn to the testTransport struct to mock the ListTasks method.
  • Implemented the ListTasks method for testTransport to use ListTasksFn if provided.
• a2aclient/grpc.go
  • Implemented the ListTasks method for grpcTransport, handling proto conversion for request and response.
• a2aclient/jsonrpc.go
  • Implemented the ListTasks method for jsonrpcTransport, sending a JSON-RPC request and unmarshaling the response.
• a2aclient/transport.go
  • Added ListTasks method signature to the Transport interface.
  • Added ListTasks method to the unimplementedTransport stub, returning errNotImplemented.
• a2apb/pbconv/from_proto.go
  • Added FromProtoListTasksResponse function to convert a protobuf ListTasksResponse to an internal a2a.ListTasksResponse.
• a2apb/pbconv/to_proto.go
  • Added ToProtoListTasksRequest function to convert an internal a2a.ListTasksRequest to a protobuf ListTasksRequest.
• a2asrv/handler.go
  • Added OnListTasks method signature to the RequestHandler interface.
  • Implemented OnListTasks for defaultRequestHandler to delegate to the taskStore.List() method.
• a2asrv/intercepted_handler.go
  • Implemented OnListTasks method for InterceptedHandler, wrapping the call with before/after interceptors.
• a2asrv/intercepted_handler_test.go
  • Added OnListTasks method to mockHandler for testing purposes, capturing call context and returning a mock response or error.
• a2asrv/jsonrpc.go
  • Added a case for jsonrpc.MethodTasksList in the handleRequest switch statement to dispatch to onListTasks.
  • Implemented onListTasks to unmarshal the JSON-RPC parameters and call the handler's OnListTasks method.
• internal/jsonrpc/jsonrpc.go
  • Defined MethodTasksList constant as 'tasks/list'.

Activity

• No specific review comments or activity have been recorded on this pull request yet.

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

The original comment regarding logging context_id in OnListTasks has been dropped. This is because OnListTasks appears to be a GET-equivalent operation, and according to repository rule 'For REST APIs, GET requests should use URL query parameters for passing parameters, not a request body', such operations should not accept a request body. The original comment implicitly accepted the presence of a request body, thus contradicting this design principle. The underlying design of OnListTasks should be reviewed against this rule.

[yarolegovich]

Thanks for working on this and sorry for the confusion. This was already implemented in release/spec-v1 branch. I marked similar issues with an appropriate label, but we should think about making the current state of the repository (with spec-v1 branch) more clear.

[birdayz]

That's great actually. What is the planned timeline to get that branch merged?
If it takes longer (1w+), are you open to merging this PR here to have an interim solution to list tasks? That would be helpful (i need it for my project; others might as well, and do not want to ship code that depends on an unmerged branch)

[yarolegovich]

That's great actually. What is the planned timeline to get that branch merged?

We'll keep it separate for a while, but the plan is to add a 1.0-alpha (or similar) release tag next week. It will include gRPC support including 0.3 gRPC and agentcard compatibility mode. Bringing other transports is the next priority.

Which transports are you using and how critical is it for you to get this earlier? Is it a new system, are you using in-memory task store?

[birdayz]

We are using our own implementation that uses Kafka (Redpanda really )topics as storage. JSON RPC Transport only. I suppose it's important but not critical. We have an inspector UI that users can use to explore sessions - without list tasks, we cannot show the exact task history. This made us implement the state in the UI - just for the debugger - which really does not work well if disconnects happen. Want to move everything server side.

[yarolegovich]

We are using our own implementation that uses Kafka (Redpanda really )topics as storage.

Nice. Have you looked into implementing a workqueue for work distribution as well? Proposal and example. It has gaps and issues (#200) but I'll be pushing for making it the default mode (with in-memory implementation) after we're done with 1.0 work. Any contributions and / or feedback very welcome.

This made us implement the state in the UI - just for the debugger - which really does not work well if disconnects happen. Want to move everything server side.

Why I asked about having a custom task store is that the reasoning behind not having delete (or list previously) was that this does not necessarily need to be a part of the protocol / SDK for implementations to use, meaning you could just expose a separate list endpoint.

Given the code already exists and the 0.3 is being retired (otherwise I'd be against having a weird cross-version transitionary state) I merged the change.