fix: update RestErrorMapper to handle RFC 7807 Problem Details error format

[ehsavoie]

This covers the core fix: the client's RestErrorMapper now reads the type URI from Problem Details responses (introduced by the server-side changes on this branch) instead of the old error/message fields, with backward compatibility for the legacy format.

Fixes #727
Fixes #730 🦕

[gemini-code-assist]

Summary of Changes

Hello, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request significantly enhances the client's error handling by integrating support for the RFC 7807 Problem Details standard. This change allows the client to correctly interpret and process more structured and detailed error responses from the server, while also ensuring that older, legacy error formats are still handled gracefully. The updates standardize how errors are presented and consumed, improving interoperability and diagnostic capabilities.

Highlights

• RFC 7807 Problem Details Support: The RestErrorMapper now supports parsing and mapping errors in the RFC 7807 Problem Details format, prioritizing it over the legacy error structure.
• Backward Compatibility: The error mapping logic ensures backward compatibility by falling back to the legacy error format if the RFC 7807 format is not detected.
• Standardized Error Responses: The RestHandler now generates error responses conforming to the RFC 7807 Problem Details specification, providing consistent and machine-readable error information.
• Error URI Mapping: A new mapErrorToURI method was introduced to translate internal A2A error types into standardized URI identifiers as required by RFC 7807.
• Updated Test Assertions: Existing test cases in RestHandlerTest were updated to assert against the new RFC 7807 Problem Details response structure, including a new helper method for consistent validation.

Changelog

• client/transport/rest/src/main/java/io/a2a/client/transport/rest/RestErrorMapper.java
  • Implemented logic to parse and prioritize RFC 7807 Problem Details error format.
  • Introduced mapRestErrorByType method for mapping RFC 7807 error type URIs to A2A exceptions.
  • Modified mapRestError to delegate to mapRestErrorByClassName for legacy error handling.
• transport/rest/src/main/java/io/a2a/transport/rest/handler/RestHandler.java
  • Imported JsonProcessingException for error handling.
  • Adjusted Javadoc formatting for improved readability across multiple methods.
  • Removed an extraneous blank line in class fields.
  • Refactored getTask method to directly catch IllegalArgumentException for invalid parameters.
  • Modified HTTPRestErrorResponse inner class to represent RFC 7807 Problem Details, including title, details, status, and type fields.
  • Added mapErrorToURI method to translate A2A errors into RFC 7807 type URIs.
  • Changed mapErrorToHttpStatus method to be static.
• transport/rest/src/test/java/io/a2a/transport/rest/handler/RestHandlerTest.java
  • Imported JsonObject and JsonParser for JSON manipulation in tests.
  • Updated numerous test assertions to validate the new RFC 7807 Problem Details format in error responses.
  • Introduced a private static helper method assertProblemDetail for consistent validation of RFC 7807 error responses.

Activity

• The author implemented the core fix to update the client's RestErrorMapper to read type URIs from Problem Details responses, ensuring backward compatibility with the legacy format.
• The pull request addresses and fixes issue [Bug]: HTTP+JSON error responses use non-standard fields #727.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request introduces support for RFC 7807 Problem Details in error responses, which is a great step towards standardizing the API. The changes correctly implement this on both the server-side for generating errors and the client-side for parsing them, including backward compatibility for the old format. My review identifies a couple of high-severity issues: one regarding inconsistent error message handling in the client's error mapper, and another related to silent failures in error serialization on the server. I've also noted a minor documentation issue. The test updates are comprehensive and effectively validate the new error format.

[ehsavoie]

/gemini review

[gemini-code-assist]

Code Review

The pull request implements support for RFC 7807 Problem Details error format, ensuring consistent and standardized error responses across the REST transport layer. The client-side RestErrorMapper has been updated to parse this new format while maintaining backward compatibility with the legacy error structure. Comprehensive unit and integration tests have been added to validate the new error handling for content type and protocol version issues, which is a significant improvement. The new README.md provides documentation for the updated error handling, enhancing clarity for consumers of the API. The review comment suggests adding an explicit content type check for the CreateTaskPushNotificationConfiguration method to ensure consistent error reporting, aligning with the project's error handling strategy.

[ehsavoie]

/gemini review

[gemini-code-assist]

Code Review

This pull request updates the REST transport layer to handle and produce error responses compliant with RFC 7807 Problem Details. The client-side RestErrorMapper is updated to parse the new format while maintaining backward compatibility. On the server-side, RestHandler now generates RFC 7807 responses, and A2AServerRoutes adds explicit content-type validation for POST endpoints. The changes are well-implemented and include thorough test updates. I have a couple of suggestions to improve maintainability and correct the documentation.

[ehsavoie]

/gemini review

[gemini-code-assist]

Code Review

This pull request is a solid improvement, successfully updating the REST transport to use RFC 7807 Problem Details for error responses. This enhances standards compliance and makes errors clearer for clients. The changes are well-executed across the client-side error mapper and server-side error generation, with backward compatibility thoughtfully maintained. The new documentation in transport/rest/README.md is a valuable addition. I have one suggestion to make the new content-type validation more robust.

[jmesnil]

@ehsavoie I think this PR needs to be revisited after the v1.0.0 spec because they changed that section in https://github.com/a2aproject/A2A/blob/v1.0.0/docs/specification.md#116-error-handling

[jmesnil]

Let's merge it and start from it before integrating the changes with the v1.0.0 tag of the spec