[Bug]: New client code does not appear to work with streaming requests

[efunneko]

What happened?

Previously I was using this SDK with the legacy A2AClient and have just spent some time upgrading to the new client code. This is working fine for message/send, but message/stream is failing in the client_task_manager code.

The problem in this code is that when the final Task message is received back from the A2A server, it triggers this error in save_task_event() within client_task_manager.py:

                raise A2AClientInvalidArgsError(
                    'Task is already set, create new manager for new tasks.'
                )

The sequence of messages is:

Client -> (initial task request) -> Server
Server -> (status update message) -> Client [Ok - creates a task in save_task_event()]
Server -> (status update message) -> Client [Ok - just updates existing task in save_task_event()]
Server -> (final task message) -> Client [FAIL - save_task_event() already has the task that was created with the first status message]

This appears to be either completely broken or my A2A server is not following the spec for streaming requests.

For now, I did a local edit to save_task_event() in the following way:

        if isinstance(event, Task):
            task_id_from_event = event.id

            if self._current_task and task_id_from_event != self._task_id:  <-- only error if it is a different task
                raise A2AClientInvalidArgsError(
                    'Task is already set, create new manager for new tasks.'
                )
            await self._save_task(event)
            return event

I am using 0.3.7, but I believe 0.3.8 also is identical for this.

Relevant log output

Code of Conduct

• I agree to follow this project's Code of Conduct

[efunneko]

I am happy to produce a PR for the change I have done above, but I would like someone to comment on whether it is how people would like to solve this issue

[mikeas1]

The issue here is that the specification requires that the stream contain exactly one Task object followed by zero or more task update events. Sending a Task object again as a stream response is technically not allowed. This is why the client is rejecting the value.

The ordering should be:
Client -> (initial task request) -> Server
Server -> (initial Task response) -> Client
Server -> (status update response) -> Client
Server -> (status update response with final = true) -> Client

This is an area that could use additional clarification in the spec. I think it's mostly hidden as a comment, rather than clearly spelled out as a requirement. Sorry about that!

I'd recommend that you change the server implementation to first send a Task, then send status updates. The client handles accumulating these events into a Task, so from the client side it should be indistinguishable.