message/send JSON-RPC result is wrapped in the SendMessageResponse oneof instead of returning the Task/Message directly

[scourtney-godaddy]

Environment

• a2a-sdk 1.0.3
• Python 3.13
• Transport: JSON-RPC (create_jsonrpc_routes, DefaultRequestHandlerV2), enable_v0_3_compat=True

Summary

For a 1.x message/send call, the JSON-RPC result comes back as {"task": {…}} (or {"message": {…}}) rather than the Task or Message object itself. A client that reads result.status and result.artifacts, which the A2A 1.0 spec describes for the unary send, finds nothing, because the payload sits one level deeper under result.task.

The task/message oneof belongs to the streaming StreamResponse. The unary message/send should return the Task or Message directly, the way tasks/get and tasks/cancel already do.

Expected

{ "jsonrpc": "2.0", "id": "1", "result": { "id": "…", "contextId": "…", "status": {…}, "artifacts": [ … ] } }

Actual

{ "jsonrpc": "2.0", "id": "1", "result": { "task": { "id": "…", "contextId": "…", "status": {…}, "artifacts": [ … ] } } }

Root cause

In a2a/server/routes/jsonrpc_dispatcher.py, _handle_send_message wraps the return value in a SendMessageResponse before serializing:

async def _handle_send_message(self, request_obj, context):
    task_or_message = await self.request_handler.on_message_send(request_obj, context)
    if isinstance(task_or_message, Task):
        return MessageToDict(SendMessageResponse(task=task_or_message))
    return MessageToDict(SendMessageResponse(message=task_or_message))

MessageToDict on a SendMessageResponse emits the oneof field name (task or message) as a key, which becomes the JSON-RPC result. The sibling handlers serialize the object directly and do not show this wrapper:

async def _handle_get_task(self, request_obj, context):
    task = await self.request_handler.on_get_task(request_obj, context)
    return MessageToDict(task, preserving_proto_field_name=False)

Impact

A2A 1.0 clients that follow the spec read the Task at result, not at result.task. Against this SDK they see an empty result and report the call as incomplete. The two shapes also disagree within one SDK: tasks/get returns the Task un-nested, message/send nests it, so a client cannot use one code path for both.

Reproduce

1. Stand up any agent with create_jsonrpc_routes(...).
2. POST a 1.x message/send (method: "SendMessage").
3. Read the response: result has a single key, task.

Suggested fix

Return the Task or Message directly from _handle_send_message, matching _handle_get_task and _handle_cancel_task:

async def _handle_send_message(self, request_obj, context):
    task_or_message = await self.request_handler.on_message_send(request_obj, context)
    return MessageToDict(task_or_message, preserving_proto_field_name=False)

The v0.3 compat path is unaffected. It already returns the Task/Message directly through the v0.3 adapter.

[rohityan]

Hi @scourtney-godaddy , thanks for reporting this. Your solution is the right approach. Would you be willing to contribute ?

[richardsonlima]

Hi there!

Opened #1196 for this.

Fixed _handle_send_message to serialize the Task/Message directly instead of wrapping it in SendMessageResponse, matching what tasks/get and tasks/cancel already do.

That alone breaks this SDK's own JSON-RPC client though, since JsonRpcTransport.send_message parses the result straight into a SendMessageResponse, which only knows the task/message oneof fields. Updated that too, and while running it against the ITK cross-SDK suite (real Go and Python peers, not mocks) found it also needs to handle a spec "kind" discriminator that peers stamp on Task/Message/Part, including nested ones in status.message, history, and parts, since our protobuf types don't declare that field. All covered now with tests, full suite plus ITK included.

One thing worth flagging here rather than only in the PR: 2 of 8 ITK scenarios still fail, both on the leg where the JSON-RPC unary call goes to go_v10 specifically. No exception, the response just comes back before the task is done, same call completes fine over grpc and http_json. Looks like an async lifecycle difference in go_v10's JSON-RPC handler rather than anything about response shape, so probably a separate issue on a2a-go or a2a-itk if it's worth chasing. Details are in the PR description.

Happy to adjust based on feedback.