gRPC client ignores google.rpc.Status/ErrorInfo, collapsing all FAILED_PRECONDITION errors to -32002 (TaskNotCancelable)

[janosSarusiKis]

The a2a-grpc client maps incoming gRPC errors to A2A errors using only the
tonic::Status code. It never decodes the google.rpc.Status / ErrorInfo carried
in the grpc-status-details-bin trailer. Because A2A spec §5.4 maps three distinct
errors to the same gRPC status FAILED_PRECONDITION, the client cannot tell them
apart and unconditionally coerces all of them to -32002 (TaskNotCancelable):

A2A error	JSON-RPC	gRPC status
TaskNotCancelableError	-32002	FAILED_PRECONDITION
PushNotificationNotSupportedError	-32003	FAILED_PRECONDITION
UnsupportedOperationError	-32004	FAILED_PRECONDITION

The specific error is meant to be recovered from the ErrorInfo detail
(reason = UPPER_SNAKE_CASE name, domain = a2a-protocol.org, AIP-193 rich error
model). The Go, Python, and .NET clients all read it; the Rust gRPC client does not.

Location

a2a-grpc/src/errors.rs, status_to_a2a_error (lines 29–40):

pub fn status_to_a2a_error(status: &tonic::Status) -> A2AError {
    let code = match status.code() {          // only the gRPC code is inspected
        tonic::Code::NotFound => error_code::TASK_NOT_FOUND,
        tonic::Code::FailedPrecondition => error_code::TASK_NOT_CANCELABLE,  // fixed -32002
        ...
    };
    A2AError::new(code, status.message())      // status.details() never read
}

Every gRPC client method routes errors through this function
(a2a-grpc/src/client.rs, .map_err(|s| status_to_a2a_error(&s))).
status.details() is never called anywhere in the crate.

Steps to reproduce
Call CreateTaskPushNotificationConfig (gRPC) against a server that does not support
push notifications. The server returns FAILED_PRECONDITION with a correct
ErrorInfo (reason=PUSH_NOTIFICATION_NOT_SUPPORTED, domain=a2a-protocol.org).

Expected: A2A code -32003 (PushNotificationNotSupported)
Actual: A2A code -32002 (TaskNotCancelable)
Observed in the agntcy-a2a interop matrix (Rust client → .NET server, gRPC). Go and
Python clients recover -32003 correctly from the same response.

Note
The SDK already has the logic to fix this — a2a-client/src/lib.rs
a2a_error_from_details() reads ErrorInfo, checks domain == "a2a-protocol.org",
and maps reason via reason_to_error_code(). It is wired into the JSON-RPC and REST
clients (jsonrpc.rs, rest.rs) but not the gRPC client. The gRPC path should
decode status.details() as google.rpc.Status, extract the ErrorInfo, and reuse
reason_to_error_code() — mirroring the other transports.

[chopmob-cloud]

Confirmed, and the same gap exists on the server side of the boundary too, so it is worth fixing both directions together.

Client (status_to_a2a_error, a2a-grpc/src/errors.rs). As you say, it maps purely on status.code(), so FailedPrecondition => TASK_NOT_CANCELABLE swallows PushNotificationNotSupported (-32003) and UnsupportedOperation (-32004). The ErrorInfo in the grpc-status-details-bin trailer is never read.

Server (a2a_error_to_status, same file). The reverse map produces tonic::Status::new(code, &err.message) with no detail attached, so all three A2A errors leave as a bare FAILED_PRECONDITION. An a2a-rs gRPC server is therefore also a non-conformant sender: a Go/Python/.NET client hitting it has nothing to disambiguate on. Fixing only the client would still leave a2a-rs servers ambiguous to everyone else.

The useful part is that the crate already has every piece; the gRPC boundary just does not use them:

• a2a::error_reason(code) gives the AIP-193 reason (TASK_NOT_CANCELABLE, etc.), and a2a::reason_to_error_code(reason) is the inverse.
• a2a::errordetails already defines ERROR_INFO_TYPE (type.googleapis.com/google.rpc.ErrorInfo) and PROTOCOL_DOMAIN (a2a-protocol.org).
• The REST error path already carries the reason (a2a-server/src/rest.rs calls error_reason(err.code)), so the reason-preserving behaviour exists in-tree on one transport; gRPC is the one that dropped it.

So the fix is wiring, not new semantics, on both sides:

• Server: attach a google.rpc.ErrorInfo detail with reason = error_reason(err.code), domain = PROTOCOL_DOMAIN, before returning the status.
• Client: read the ErrorInfo from the status details, and if present resolve the precise code via reason_to_error_code(reason), falling back to the current status.code() mapping when no detail is present (so peers that do not send ErrorInfo still degrade to today's behaviour).

One implementation note, since it needs a dependency decision: the existing TypedDetail is serde/JSON and only feeds the REST/JSON-RPC path, so it cannot encode the protobuf grpc-status-details-bin trailer directly. The clean way is to add tonic-types (0.14, matching the workspace tonic), whose StatusExt gives with_error_details / get_error_details and an ErrorInfo type; alternatively encode google.rpc.Status by hand with the prost-types already in the tree. Either keeps the client fallback intact.

One hardening note, since this makes the client parse details from the server's trailer and in A2A the server may be another party's agent: decode defensively. Keep the resolution fail-closed on reason_to_error_code (it returns Option, so an unknown or unexpected reason falls through to the status.code() mapping rather than being trusted), and use the get_error_details result rather than unwrapping, so a malformed or oversized detail from a hostile peer degrades to today's behaviour instead of panicking.

Worth a mapping test in both directions (code -> status carries the reason, and status-with-reason -> the specific code) so the three FAILED_PRECONDITION cases are pinned, since a code-only round trip cannot tell them apart.