From Quarkus issue tracker: https://github.com/quarkusio/quarkus/issues/3655
(note there's a reproducer attached to the Quarkus issue)

Description

It seems that when using the asynchronous REST Client operators (either CompletionStage, or rxJava 2.x operators), when the REST client encounters an error like 404, it is not able to call any exception mappers correctly, thus making it impossible to handle any HTTP errors from the rest client.

Expected behavior
The exceptions returned from asynchronous HTTP Client calls from should be proper errors, not just Handler Errors when using CompletionStage

Actual behavior
The output exception if of type ExceptionMapping$HandlerException, not the actual exception that was thrown (Like a NotFoundException, or similar).

To Reproduce
Steps to reproduce the behavior:

Open the attached project.
Setup a mock server. I use Mockoon for this purpose, but any dummy server with a "404" response will suffice to reproduce the problem.
Visit the "GreetingResource". There are 3 endpoints there, one calling a rest endpoint synchronously, and the other ones asynchronously (one with Completion Stage, and one with RXJava).
Put breakpoints in lines 29 and 43 (in the erroneous callbacks of the REST call actions).
Run with the remote debugger. Call the synchronous API. It throws an error 404 (correct behaviour). Next, hit any of the other two endpoints.
The execution will stop at one of your breakpoints. Check the type of the throwable. It's an ExceptionMapping$HandlerException type, which reports garbage, and not the actual exception holding the 404 error. The original error (which should be 404) is not able to be seen!

This happens with many server and error configurations - this is just a simple case I was able to prepare.

Environment (please complete the following information):

Output of java -version: 1.8
Quarkus version or git rev: 0.21.1

Additional context
It seems that in the case of asynchronous calls to the REST Client, the mapException(Method method) method is not called. In the synchronous version of the REST Client, this method is able to be called, thus the predefined exception mappers can be called appropriately. Custom exception mappers provided the developer also cannot be used because of this issue.

This issue renders the REST Client clunky in asynchronous scenarios - the real cause of the HTTP error in async mode is silenced.