fix: validate A2A version and extensions on all gRPC handler methods

[ez-lbz]

What changed

1. Enforce A2A version and extension validation on all gRPC handler methods

Problem: In GrpcHandler, only sendMessage and sendStreamingMessage called A2AVersionValidator.validateProtocolVersion + A2AExtensions.validateRequiredExtensions. The remaining methods — getTask, listTasks, cancelTask, createTaskPushNotificationConfig, getTaskPushNotificationConfig, listTaskPushNotificationConfigs, subscribeToTask, deleteTaskPushNotificationConfig, getExtendedAgentCard — skipped validation entirely, so clients using an incompatible protocol version (or missing required extensions) were served instead of being rejected.

Fix (transport/grpc/src/main/java/org/a2aproject/sdk/transport/grpc/handler/GrpcHandler.java):

• Added A2AVersionValidator.validateProtocolVersion(getAgentCardInternal(), context) and A2AExtensions.validateRequiredExtensions(getAgentCardInternal(), context) immediately after createCallContext(...) in all nine previously-unvalidated methods, mirroring the existing sendMessage/sendStreamingMessage pattern. For subscribeToTask the checks are placed after installForkedContextWrapper, matching sendStreamingMessage.

Fix (transport/grpc/src/test/java/org/a2aproject/sdk/transport/grpc/handler/GrpcHandlerTest.java):

• Added testVersionNotSupportedErrorOnGetTask: a handler with an incompatible requested protocol version ("2.0" vs the card's "1.0") now fails getTask with gRPC UNIMPLEMENTED (mapped from VersionNotSupportedError). Previously getTask skipped validation and would have returned the task.

Behavior change: gRPC requests with an incompatible A2A-Version header or missing required extensions are now rejected on all methods instead of only the two streaming/unary message methods. Requests carrying no version header are unaffected (they default to "0.3" compatibility per spec, and validation passes when the card supports a compatible version).

Testing

• mvn -pl transport/grpc test — 41 tests run, 0 failures, 0 errors, 0 skipped (BUILD SUCCESS), including the new regression test testVersionNotSupportedErrorOnGetTask.

[kabir]

Hi @ez-lbz thanks it looks good! Just a small suggestion to centralize the code.

The main question there is whether installForkedContextWrapper() can happen after doing the validation for the streaming calls which is what will happen if we go with my suggestion. sendStreamingMessage() currently creates this wrapper before its validation.

If the wrapper needs to be created before validation we can probably massage createCallContext() a bit to conditionally install the wrapper before validation

[kabir]

I wonder if we could just put these two lines inside createCallContext()?

[ez-lbz]

Good suggestion — done. validateProtocolVersion and validateRequiredExtensions now live inside createCallContext(), so all gRPC handler methods (getTask, listTasks, cancelTask, push-config methods, subscribe, streaming) validate through a single path.

Regarding your question on ordering: installForkedContextWrapper() is independent of the validation — it only attaches a forked gRPC Context around agent-executor runnables, and validation doesn't touch that. Moving validation before the wrapper install is safe, and a failed validation now skips the fork entirely. GrpcHandlerTest passes (41 tests, 0 failures).