feat(gax): add getErrorInfoList to ErrorDetails

[westarle]

No description provided.

[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 enhances the ErrorDetails class by providing a mechanism to access all ErrorInfo messages present in a single error response. This is crucial for scenarios where a single error might contain multiple detailed error explanations, improving the robustness of error handling within the system.

Highlights

• New Feature: Multiple ErrorInfo Retrieval: Introduced a new method, getErrorInfoList(), to the ErrorDetails class, allowing for the retrieval of all ErrorInfo messages when an error response contains multiple such details.
• Internal Unpacking Utility: Added a private utility method, unpackList(), to ErrorDetails to facilitate the unpacking of multiple Any protocol buffer messages into a list of a specified type, handling potential parsing exceptions.
• Comprehensive Testing: Included new unit tests to verify the correct behavior of getErrorInfoList() and unpackList(), covering scenarios such as null raw error messages and the unpacking of multiple ErrorInfo instances.

Changelog

• gax-java/gax/src/main/java/com/google/api/gax/rpc/ErrorDetails.java
  • Added getErrorInfoList() method to retrieve a list of ErrorInfo messages.
  • Implemented unpackList() method to unpack multiple Any messages into a list.
  • Imported ArrayList and Collections for list manipulation.
• gax-java/gax/src/test/java/com/google/api/gax/rpc/ErrorDetailsTest.java
  • Added a test for unpackList() to ensure it returns an empty list when raw error messages are null.
  • Added a test for getErrorInfoList() to verify it correctly unpacks and returns multiple ErrorInfo messages.

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 a new method getErrorInfoList() to the ErrorDetails class, allowing retrieval of all ErrorInfo messages from an error response, which is a useful enhancement. The implementation is clean, and it includes unit tests for the happy path and null input cases. I have one suggestion to improve test coverage by adding a test for the exception handling path.

[gemini-code-assist]

The new unpackList method can throw a ProtocolBufferParsingException if unpacking fails, which is consistent with the existing unpack method. To ensure complete test coverage for the new logic, please consider adding a test case for this exception scenario, similar to the existing unpack_shouldThrowExceptionIfUnpackingErrorMassageFailed test.

  }

  @Test
  void unpackList_shouldThrowExceptionIfUnpackingErrorMessageFailed() {
    Any malformedErrorType =
        Any.newBuilder()
            .setTypeUrl("type.googleapis.com/google.rpc.ErrorInfo")
            .setValue(ByteString.copyFromUtf8("This is an invalid message!"))
            .build();
    errorDetails =
        ErrorDetails.builder().setRawErrorMessages(ImmutableList.of(malformedErrorType)).build();
    ProtocolBufferParsingException exception =
        assertThrows(
            ProtocolBufferParsingException.class, () -> errorDetails.unpackList(ErrorInfo.class));
    Truth.assertThat(exception.getMessage())
        .isEqualTo(
            String.format(
                "Failed to unpack %s from raw error messages", ErrorInfo.class.getSimpleName()));
  }

References

1. The repository style guide states that all new logic should be accompanied by tests. The exception handling path in the new unpackList method is currently not covered by tests. ^(link)

[blakeli0]

Per aip-193, Each type of detail payload must be included at most once.

I think this is theoretically possible but a violation of AIP.

[westarle]

thank you, that's extremely helpful!