Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

REST Client Replaces WebApplicationException Instances Returned By ExceptionMapper #42275

Closed
gilday opened this issue Aug 1, 2024 · 2 comments · Fixed by #42290
Closed

REST Client Replaces WebApplicationException Instances Returned By ExceptionMapper #42275

gilday opened this issue Aug 1, 2024 · 2 comments · Fixed by #42290
Labels
area/rest-client kind/bug Something isn't working
Milestone

Comments

@gilday
Copy link

gilday commented Aug 1, 2024

Describe the bug

REST Client's that use an exception mapper to return custom exception types may have those instances unexpected replaced by the RestClientRequestContext.

When the exception returned by an exception mapper is itself a subclass of WebApplicationException, then logic in RestClientRequestContext replaces that instance with a new instance of ClientWebApplicationException.

Expected behavior

The exception instance returned by the exception mapper is thrown.

Actual behavior

A new exception of type ClientWebApplicationException is thrown.

How to Reproduce?

The failing Quarkus test in the attached reproducer demonstrates the actual vs expected behavior of this exception mapper.

@RegisterRestClient(configKey = "greeting-service")
public interface GreetingService {

  /**
   * Retrieves a greeting for the given individual.
   *
   * @param name name of the individual
   * @return a greeting
   */
  @GET
  @Path("/greeting")
  String greet(@QueryParam("name") String name);

  /**
   * Because {@link GreetingException} extends {@link jakarta.ws.rs.WebApplicationException},
   * Quarkus will replace the instance returned by this method with a new {@link
   * ClientWebApplicationException}.
   */
  @ClientExceptionMapper
  static RuntimeException toException(Response response) {
    if (response.getStatus() == 400) {
      final var error = response.readEntity(GreetingError.class);
      return new GreetingException(Response.Status.BAD_REQUEST, error);
    }
    return null;
  }
}

quarkus-rest-client-exception-mapper-changes-type.zip

Output of uname -a or ver

Darwin pixee-mbp-gilday.localdomain 23.5.0 Darwin Kernel Version 23.5.0: Wed May 1 20:12:58 PDT 2024; root:xnu-10063.121.3~5/RELEASE_ARM64_T6000 arm64

Output of java -version

openjdk version "21.0.3" 2024-04-16 LTS OpenJDK Runtime Environment Temurin-21.0.3+9 (build 21.0.3+9-LTS) OpenJDK 64-Bit Server VM Temurin-21.0.3+9 (build 21.0.3+9-LTS, mixed mode)

Quarkus version or git rev

3.13.0

Build tool (ie. output of mvnw --version or gradlew --version)

Apache Maven 3.9.7 (8b094c9513efc1b9ce2d952b3b9c8eaedaf8cbf0) Maven home: /Users/jgilday/.m2/wrapper/dists/apache-maven-3.9.7-bin/33482774/apache-maven-3.9.7 Java version: 21.0.3, vendor: Eclipse Adoptium, runtime: /Library/Java/JavaVirtualMachines/temurin-21.jdk/Contents/Home Default locale: en_US, platform encoding: UTF-8 OS name: "mac os x", version: "14.5", arch: "aarch64", family: "mac"

Additional information

No response

@gilday gilday added the kind/bug Something isn't working label Aug 1, 2024
Copy link

quarkus-bot bot commented Aug 1, 2024

/cc @cescoffier (rest-client), @geoand (rest-client)

@geoand
Copy link
Contributor

geoand commented Aug 2, 2024

Thanks for reporting.

I'll have to think of how to handle this one

geoand added a commit to geoand/quarkus that referenced this issue Aug 2, 2024
geoand added a commit to geoand/quarkus that referenced this issue Aug 2, 2024
… a custom mapper

The idea is that if a user has opted to create an exception,
we should always honor it - even if it's a WebApplicationException

Fixes: quarkusio#42275
geoand added a commit to geoand/quarkus that referenced this issue Aug 2, 2024
… a custom mapper

The idea is that if a user has opted to create an exception,
we should always honor it - even if it's a WebApplicationException

Fixes: quarkusio#42275
geoand added a commit to geoand/quarkus that referenced this issue Aug 5, 2024
… a custom mapper

The idea is that if a user has opted to create an exception,
we should always honor it - even if it's a WebApplicationException

Fixes: quarkusio#42275
geoand added a commit that referenced this issue Aug 5, 2024
Don't convert WebApplicationException in REST Client when produced by a custom mapper
@quarkus-bot quarkus-bot bot added this to the 3.14 - main milestone Aug 5, 2024
danielsoro pushed a commit to danielsoro/quarkus that referenced this issue Sep 20, 2024
… a custom mapper

The idea is that if a user has opted to create an exception,
we should always honor it - even if it's a WebApplicationException

Fixes: quarkusio#42275
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/rest-client kind/bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants