Payload too large question

[juanjosgu]

We are trying to send an image to A2A as part of a message payload. Following the JSON-RPC contract, we build the message with multiple parts (one text part and one file part).

When the file part contains bytes encoded as base64, the request fails (Payload too large exception). Example snippet:

"message": {
  "role": "user",
  "parts": [
    {
      "kind": "text",
      "text": "Text query"
    },
    {
      "kind": "file",
      "file": {
        "bytes": "<base64 image>",
        "mime_type": "image/png"
      }
    }
  ],
  "messageId": "5678",
  "kind": "message"
}

Questions

• Is embedding base64 in the bytes field the supported approach?
• If not, what is the recommended way to send images (e.g. raw binary upload, presigned URL, multipart)?
• Would you consider supporting base64 input for convenience in client libraries?

[mikeas1]

Is embedding base64 in the bytes field the supported approach?

Yes, it is actually required to use base64 encoded values in the bytes field of FileWithBytes. See the type specification.

Would you consider supporting base64 input for convenience in client libraries?

Do you mean a convenience function for going from a bytes value to a FilePart with a FileWithBytes value? Something like create_file_part(content: bytes, mime_type: str) -> FilePart. Sure, if this is a common pattern I would accept a PR to add a utility function for it.

To address your underlying issue: it sounds like you are producing an image that is too large to fit in an A2A request/response message. Your best bet, as unfortunate as it is, is to return a URI value that the client can use to retrieve the content. Signed URLs when using cloud storage systems are a good option, if that's available to you.

You could technically use Artifact streaming to stream parts of the image back to a client if the client were connected via SSE. However that will end up with the same issue due to all of the parts getting accumulated in the Task, making the size of the Task object exceed the max payload size. This is an area that we could potentially improve in future versions of the protocol, though it needs to be balanced with maintaining simplicity (as much as there is of that).

Assigning back to you in case you have further questions. If not, feel free to close this issue.