a2a-error-handling

A2A Error Handling

Before writing code

Fetch live docs:

1. Fetch https://a2a-protocol.org/latest/specification/ for the error handling section
2. Web-search site:github.com a2aproject A2A error codes for error code definitions
3. Web-search site:github.com a2aproject a2a-samples error for error handling examples
4. Fetch SDK docs for error classes and exception types

Conceptual Architecture

Error Categories

A2A has three categories of errors:

1. JSON-RPC Protocol Errors — Malformed requests, invalid methods, parse failures
2. A2A-Specific Errors — Protocol-level issues specific to A2A operations
3. Task-Level Failures — The task itself fails during processing (task state → failed)

JSON-RPC 2.0 Error Format

All errors follow the JSON-RPC 2.0 error response format:

{
  "jsonrpc": "2.0",
  "id": "request-id",
  "error": {
    "code": -32600,
    "message": "Invalid Request",
    "data": { "details": "..." }
  }
}

Standard JSON-RPC Error Codes

| Code | Name | Meaning | |------|------|---------| | -32700 | Parse error | Invalid JSON | | -32600 | Invalid request | Not a valid JSON-RPC request | | -32601 | Method not found | Method doesn't exist or isn't supported | | -32602 | Invalid params | Method parameters are invalid | | -32603 | Internal error | Server internal error |

A2A-Specific Error Codes

| Code | Name | Meaning | |------|------|---------| | -32001 | TaskNotFoundError | The referenced taskId doesn't exist | | -32002 | TaskNotCancelableError | Task is in a state that can't be canceled (terminal state) | | -32003 | PushNotificationNotSupportedError | Agent doesn't support push notifications | | -32004 | UnsupportedOperationError | The requested operation is not supported | | -32005 | ContentTypeNotSupportedError | Client's accepted output modes don't match agent's capabilities | | -32006 | InvalidAgentResponseError | The agent returned an invalid or malformed response | | -32007 | ExtendedAgentCardNotConfiguredError | Extended Agent Card is not configured | | -32008 | ExtensionSupportRequiredError | A required extension is not supported | | -32009 | VersionNotSupportedError | The requested protocol version is not supported |

Task Failure vs Protocol Error

Important distinction:

• Protocol errors return a JSON-RPC error response — the request itself was invalid or couldn't be processed
• Task failures return a normal response with the task in failed state — the request was valid but the task's processing failed

Example: If a client sends message/send with invalid JSON → -32700 (protocol error). If a client sends a valid message but the agent's LLM call fails → task state becomes failed with an error message.

Server-Side Error Handling

The server should:

1. Validate JSON-RPC structure — Return -32600/-32700 for malformed requests
2. Validate method — Return -32601 for unsupported methods
3. Validate parameters — Return -32602 for invalid params
4. Check task existence — Return -32001 for unknown task IDs
5. Check capabilities — Return -32003/-32005 for unsupported features
6. Handle extended card — Return -32007 if extended Agent Card is not configured
7. Handle internal errors — Return -32603 for unexpected server errors
8. Set task state — Transition to failed for task-level processing errors

Client-Side Error Handling

The client should:

1. Parse the response — Check for error field vs result field
2. Handle by error code — Different codes need different responses
3. Retry transient errors — -32603 (internal error) may be retryable
4. Don't retry permanent errors — -32601 (method not found) won't succeed on retry
5. Handle task failures — Check task state for failed and read the error message
6. Fallback — Try alternative agents if one fails

Retry Strategy

| Error Code | Retryable? | Strategy | |-----------|------------|----------| | -32700 | No | Fix the request | | -32600 | No | Fix the request | | -32601 | No | Method not available on this agent | | -32602 | No | Fix the parameters | | -32603 | Yes | Exponential backoff, max 3 retries | | -32001 | No | Task doesn't exist | | -32002 | No | Task can't be canceled | | -32005 | No | Content type mismatch | | -32007 | No | Extended Agent Card not configured |

Best Practices

• Always include meaningful error messages, not just codes
• Use the data field in JSON-RPC errors for additional debugging context
• Log errors with request IDs and task IDs for traceability
• Implement circuit breakers for agents that are consistently failing
• Set task state to failed with a descriptive message when processing fails
• Don't expose internal implementation details in error messages to external clients
• Implement graceful degradation — if one agent in a pipeline fails, handle it upstream
• Test error paths explicitly — they're as important as the happy path

Fetch the specification for the complete list of error codes, their semantics, and any error handling requirements before implementing.