test(showcase): Add gRPC and HttpJson Showcase ITs to verify Error Details

[nnicolee]

Description

This PR introduces E2E integration test coverage for standard and custom error details using the FailEchoWithDetails RPC in Showcase, validating the exception propagation and deserialization pipeline across both gRPC and HTTP/JSON transports.

Key Changes

• gRPC Transport Verification:
  • Verifies unpacking and correctness of all standard error details (e.g. ErrorInfo, RetryInfo, DebugInfo, QuotaFailure, PreconditionFailure, BadRequest, RequestInfo, ResourceInfo, Help, LocalizedMessage).
  • Verifies that Showcase-specific custom trailers (e.g. PoetryError) are successfully unpacked and mapped into the client-side ErrorDetails.
  • Verifies dynamic message propagation inside custom trailers when parameters are passed to the request.
• HTTP/JSON Transport Verification:
  • Verifies that error status code mapping (e.g. ABORTED) propagates correctly.
  • Handles GAX's HTTP/JSON parser boundaries when dealing with unregistered custom types (like PoetryError) in JSON status payloads.

[gemini-code-assist]

Code Review

This pull request introduces a new integration test class, ITErrorDetails.java, to verify that standard and custom error details are correctly parsed and unpacked from ApiException for both gRPC and HTTP/JSON clients. The review feedback highlights two main areas for improvement: ensuring exception-safe resource cleanup in destroyClients() to prevent potential resource leaks if one of the clients fails to close, and avoiding the use of fully qualified class names when there are no naming conflicts to improve code readability.

[lqiu96]

Lint issue looks external:

[ERROR] Failed to execute goal com.spotify.fmt:fmt-maven-plugin:2.25:check (default-cli) on project grpc-google-cloud-sql-v1: Found 6 non-complying files, failing build -> [Help 1]
[ERROR] Failed to execute goal com.spotify.fmt:fmt-maven-plugin:2.25:check (default-cli) on project grpc-google-cloud-sql-v1beta4: Found 1 non-complying files, failing build -> [Help 1]

Hmm, maybe we try and update the branch. Maybe got fixed in main

[nnicolee]

/gemini review

[gemini-code-assist]

Code Review

This pull request introduces a new integration test class, ITErrorDetails.java, to verify that standard and custom error details are correctly propagated and deserialized over both gRPC and HTTP/JSON transports. The feedback suggests improving the @AfterAll teardown method to ensure exception-safe cleanup of the clients in reverse order of creation (LIFO) and to include null checks to prevent potential NullPointerExceptions.

[gemini-code-assist]

When managing multiple closeable resources, they should be closed in the reverse order of their creation (LIFO) to prevent resource leaks. Additionally, the closing and termination process should be exception-safe so that a failure in closing or awaiting one client does not prevent the other from being properly cleaned up. Also, adding null checks prevents potential NullPointerExceptions if client initialization fails in @BeforeAll.

  @AfterAll
  static void destroyClients() throws InterruptedException {
    try {
      if (httpjsonClient != null) {
        httpjsonClient.close();
      }
    } finally {
      if (grpcClient != null) {
        grpcClient.close();
      }
    }
    try {
      if (httpjsonClient != null) {
        httpjsonClient.awaitTermination(
            TestClientInitializer.AWAIT_TERMINATION_SECONDS, TimeUnit.SECONDS);
      }
    } finally {
      if (grpcClient != null) {
        grpcClient.awaitTermination(
            TestClientInitializer.AWAIT_TERMINATION_SECONDS, TimeUnit.SECONDS);
      }
    }
  }

References

1. When managing a collection of closeable resources (e.g., scopes), ensure they are closed in the reverse order of their creation (LIFO). The implementation must be exception-safe to prevent resource leaks, meaning all opened resources should be closed even if exceptions occur during their creation or closing.
2. When using lazily initialized resources (such as ExecutorService), ensure that teardown or close methods perform explicit null checks before invoking methods on them to prevent NullPointerException.