Blocking call with reactive rest client produces lacklustre stacktraces

[mapuci]

I have no idea if I'm describing a bug or if it is a desired behavior.
quarkus-rest-client-reactive should support reactive and blocking scenarios equally well. It should be a drop-in replacement for blocking quarkus-rest-client.
We are talking about blocking scenarios here.
There is a big difference in where the response is handled: quarkus-rest-client blocks the caller thread; quarkus-rest-client-reactive blocks the caller thread but still handles the response in an IO thread.

Please inspect a simple reproducer example (1 source file and a README):
https://github.com/MatejPucihar/blocking-call-reactive-client-stacktrace/tree/main
We have two rest endpoints, 'callMeFromSwagger' and 'callMeFromRestClient'. The first calls the second. The second returns 400, and the first throws an exception and logs it (it is 500 there).
We are calling an endpoint with an invalid argument (a blank string on @notblank queryParameter), so the exception is, of course, expected.
As you can see, the logged stack trace does not contain the caller information; there is no way of knowing where in the code the restClient was invoked. There should be information about TestResource. callMeFromSwagger(..) in the stack trace

The caller's worker thread is blocked at org.jboss.resteasy.reactive.client.impl.InvocationBuilderImpl#unwrap,
and the original exception is thrown (from the IO thread).
In my opinion, the exception there should be wrapped in a new exception. It would result in much more informative exceptions being thrown.

[quarkus-bot[bot]]

/cc @Sgitario (rest-client), @brunobat (opentelemetry,tracing), @cescoffier (rest-client), @geoand (rest-client), @radcortez (opentelemetry,tracing)

[geoand]

We could capture the stacktrace of when the method is called and then add it in but I am not so sure how useful it would be.

@cescoffier @Sgitario @FroMage what's your take?

[mapuci]

You provide info about which restClient method was invoked, e.g.

2023-06-06 08:34:49,262 ERROR [io.qua.ver.htt.run.QuarkusErrorHandler] (executor-thread-1) HTTP Request to /test/callMeFromSwagger failed, error id: 1ef6343d-3100-4dc1-8ac0-cfe8b829de5a-1: org.jboss.resteasy.reactive.ClientWebApplicationException: Received: 'Bad Request, status code 400' when invoking: Rest Client method: 'org.example.SelfClient#callMeWithRestClient'

org.example.SelfClient#callMeWithRestClient in the above example.

You do not provide who called it. And a single rest client method can be called from multiple places in the code. So the provided stacktrace is lackluster :)

I must admit, I do not have much experience with reactive. But in the blocking world, we usually investigate stacktraces when something goes wrong...

[geoand]

But in the blocking world, we usually investigate stacktraces when something goes wrong

I think no one in the Java world needs to be reminded of this 😉, so you likely misunderstood what and why I was asking my colleagues for their input

[Sgitario]

@cescoffier @Sgitario @FroMage what's your take?

I think there are several points raised here:

• On one side, yes, we should improve the thrown exception to include as much information about the cause as we can. We should report an issue to improve this.

• On another side, about blocking, not-blocking. The handlers, and filters are meant not to be blocking by default. Still, we are trying to improve the user experience, for example: Support blocking exception mappers in REST Client Reactive #32644

[Sgitario]

I provide a possible solution to this: #33869
I think we can continue the discussion there @MatejPucihar

[FroMage]

@geoand In the Redpipe Web Framework that predated Quarkus, I always recorded stack traces when creating futures (Uni equivalent) to be able to attach "origin" stack traces on subsequent failures.

I've always wondered why Mutiny doesn't provide support for something equivalent. It would help users SO MUCH.

[maxandersen]

@geoand that grabbing of stacktrace would only work in devmode I assume?

[geoand]

Why do you think that?

We can get the stacktrace when the proxy method is called in any mode.
The "problem" is how to enhance the actual stacktrace with what we captured (and stashed) - i.e. do we add it as a cause, as a suppressed, something else?

[maxandersen]

Ah okey. I just thought there would unnecessary overhead grabbing it before exception actually happens. If not then all good.

[geoand]

Well, there certainly is overhead in grabbing the stacktrace, but under normal circumstances it should be dwarfed by the REST call itself