[Bug][compat-0.3][HTTP+JSON] RestTransport_v0_3 rejects valid FilePart.name

[xiongus]

Describe the bug

With the latest Maven Central release, 1.2.0.Final, the v0.3 HTTP+JSON client accepts an initial WORKING task but fails when polling the completed task if an artifact contains a file name.

The failure is:

org.a2aproject.sdk.compat03.spec.A2AClientException_v0_3:
Failed to get task: com.google.protobuf.InvalidProtocolBufferException:
Cannot find field: name in message a2a.v1.FilePart

Environment

• A2A Java SDK: 1.2.0.Final
• Modules:
  • a2a-java-sdk-compat-0.3-client
  • a2a-java-sdk-compat-0.3-client-transport-rest
• Protocol advertised by the server: 0.3.0
• Preferred transport: HTTP+JSON
• JDK used for the minimal reproducer: 25.0.2

Reproduction

1. Resolve a v0.3 Agent Card advertising HTTP+JSON.
2. Build a Client_v0_3 with RestTransport_v0_3.
3. Send a Message_v0_3.
4. The initial task response is parsed successfully and has state WORKING.
5. Poll it with:

client.getTask(
    new TaskQueryParams_v0_3(taskId),
    new ClientCallContext_v0_3(Map.of(), Map.of())
);

6. Once the task is complete, the server returns an artifact containing this valid v0.3 file object:

{
  "artifacts": [
    {
      "artifactId": "html-report",
      "name": "report.html",
      "parts": [
        {
          "file": {
            "fileWithBytes": "PGh0bWw+Li4uPC9odG1sPg==",
            "mimeType": "text/html",
            "name": "report.html"
          }
        }
      ]
    }
  ]
}

The poll then fails in RestTransport_v0_3.getTask() while merging ProtoJSON.

Expected behavior

The completed task should be parsed successfully and the file name should be preserved as FileWithBytes_v0_3.name.

The A2A v0.3 specification defines FileBase.name as an optional field:

https://a2a-protocol.org/v0.3.0/specification/#66-filebase-object

Suspected regression

The current compatibility Proto does not contain FilePart.name:

https://github.com/a2aproject/a2a-java/blob/main/compat-0.3/spec-grpc/src/main/proto/a2a.proto#L213-L219

Its domain record already supports the value:

FileWithBytes_v0_3(String mimeType, String name, String bytes)

but ProtoUtils_v0_3.FromProto.filePart() currently supplies null for the name.

This field was previously reported in #364 and added to the old spec-grpc module by #392, but the fix appears not to have been carried into the later compat-0.3/spec-grpc module.

Suggested fix

• Add string name = 4; to the compat-0.3 FilePart Proto.
• Preserve name and mime_type in both directions in ProtoUtils_v0_3.
• Add an HTTP+JSON polling test whose completed task contains a named FileWithBytes artifact.

This is reproducible against a real official-SDK-based v0.3 server; request submission and task execution both succeed, and only final task decoding fails.

[kabir]

Hi,

I have looked a bit at this one, and it is a bit messy unfortunately.

The PR and the issue you mention was from work we did before 1.0 was finalized, trying to stay on top of the work happening in the https://github.com/a2aproject/A2A specification repository. However, this never made it into any of the 0.3.x release as far as I know, and the branch got repurposed for the work on 1.0.

In the 0.3.0 version of the a2a.proto, which is the basis for the REST and gRPC protocols in the 0.3.0 work and compat layer there is no such name field.

However, then the spec text has a filename for the FilePart.

So IMO this is a bug in the spec. A lot of work was done in the 1.0 version of the spec to avoid inconsistencies like these going forward, by making the a2a.proto the absolute source of truth.

That said, I think we can add handling of the field to be a bit more lenient in the 0.3 case for the compat-0.3 layers, and add handling to allow the file name.