Debugging RESTEasy Reactive errors without body (400, 401)

[ia3andy]

Description

It is very hard to find out where the problem originate from when using different Quarkus extensions (RESTEasy, hibernate validator, security, CSRF, ...)

What I did recently is this:

import io.quarkus.logging.Log;
import io.quarkus.runtime.LaunchMode;
import io.smallrye.mutiny.Uni;
import jakarta.enterprise.context.ApplicationScoped;
import jakarta.ws.rs.Priorities;
import jakarta.ws.rs.WebApplicationException;
import jakarta.ws.rs.core.Response;
import org.jboss.resteasy.reactive.server.ServerExceptionMapper;

@ApplicationScoped
public class ExceptionMapper {

    @ServerExceptionMapper(priority = Priorities.USER + 2)
    public Uni<Response> mapException(Throwable exception) {
        if (Log.isDebugEnabled() || LaunchMode.current().isDevOrTest()) {
            Log.error(exception.getMessage(), exception);
        }
        if(exception instanceof WebApplicationException) {
            return Uni.createFrom().item(((WebApplicationException) exception).getResponse());
        }
        return Uni.createFrom().item(Response.serverError().build());
    }

}

Which allows me to easilly debug issues in dev/test and also possibility in prod (when the logger is set for it)

Implementation ideas

Not sure how we could make this easier for the users.

[quarkus-bot[bot]]

/cc @FroMage (resteasy-reactive), @geoand (resteasy-reactive), @stuartwdouglas (resteasy-reactive)

[ia3andy]

FYI: I also created this issue for people having the same question on Google

[ia3andy]

@geoand would it make sense to add something similar by default in RR?

[geoand]

Doesn't the debugging information provided in https://quarkus.io/guides/resteasy-reactive#accessing-request-parameters give you enough information?

[sberyozkin]

@ia3andy FYI, @michalvavrik is finalizing PR which will allow observing security events

[ia3andy]

Doesn't the debugging information provided in https://quarkus.io/guides/resteasy-reactive#accessing-request-parameters give you enough information?

It depends on the case, for example I had a deserialization issue with Jackson and it was very impossible to debug without the exception stacktrace.

[geoand]

quarkus.log.category."org.jboss.resteasy.reactive.common.core.AbstractResteasyReactiveContext".level=DEBUG (also mentioned in the docs) should cover that

[ia3andy]

@sberyozkin any progress on the PR?

[michalvavrik]

@sberyozkin any progress on the PR?

Security events are in https://quarkus.io/version/main/guides/security-customization#observe-security-events

It won't help you with non-security stuff: bad requests, deserializations etc. so FWIW I think you should help @geoand understand what more is needed; I can see his suggestion to enable debugging that could help.

[FroMage]

Well, let's put it another way: why do we not log something minimal in DEV/TEST modes to explain why we're returning a non OK status? A one-liner giving the status, http reason (helpful) and thrower?

400 (Bad Request) thrown by `CsrfRequestResponseReactiveFilter.verifyCsrfToken #151`

Now, I'm actually including my pet peeve here, and there's a trick, because this is not throwing any exception, it's calling context.abortWith(Response), but frankly this should also be easily trackable.

If you log the location of the creators of any Exception or abortWith this will yield SO MUCH dev productivity improvements when dealing with security or filters or exception mappers that it will blow people's mind.

If you add a simple config option such as quarkus.rest.log-non-ok-statuses=yes|long to enable this on PROD, or to add a stack trace, this will be EVEN BETTER.

[ia3andy]

@FroMage that would be awesome!