4.0.0 JAX-RS `ExceptionMapper` disrupts metrics, health endpoints

[tjquinno]

Environment Details

• Helidon Version: 4.0.0
• Helidon SE or Helidon MP MP
• JDK version:
• OS:
• Docker version (if applicable):

---

Problem Description

Adding a general, catch-all JAX-RS exception mapper to an app disrupts the metrics and health endpoints (and perhaps other observers' endpoints as well).

As coded in the repo, the MP QuickStart app correctly responds to the /health and /metrics endpoints.

If you add an exception mapper to the app, then it is invoked when the /health and /metrics endpoints are accessed.

Steps to reproduce

1. cd examples/quickstarts/helidon-quickstart-mp
mvn package

   The preceding commands work, including running unit tests which ping the health and metrics endpoints.

2. Add the following class to the MP QuickStart app:

   package io.helidon.examples.quickstart.mp;
   
   import jakarta.ws.rs.core.Response;
   import jakarta.ws.rs.ext.ExceptionMapper;
   import jakarta.ws.rs.ext.Provider;
   
   @Provider
   public class GeneralExceptionMapper implements ExceptionMapper<Exception>  {
       @Override
       public Response toResponse(Exception e) {
           return Response.status(500).entity(e.getMessage()).build();
       }
   }

3. Now mvn package fails during the /health or /metrics endpoint tests because the exception mapper returns 500 responses.

[tomas-langer]

The exception handler defined in the example cannot work, as it transforms any kind of exception into an internal server error, including JAX-RS web excepetions that handle other states (such as 404 not found, 401 unauthorized, and 403 forbidden).

At least 404 MUST be correctly handled, as otherwise Helidon does not understand that the problem was that the endpoint was not found. When Jersey returns 500, we consider that final response and must return it to the caller.

Jersey has priority over other Helidon endpoints, so we first try to serve anything using Jersey, and only then we resolve Helidon WebServer routing.

The (minimal) correct handler:

    @Provider
    public static class GeneralExceptionMapper implements ExceptionMapper<Exception> {
        @Override
        public Response toResponse(Exception e) {
            if (e instanceof NotFoundException web) {
                return web.getResponse();
            }
            return Response.status(500).entity(e.getMessage()).build();
        }
    }

[tomas-langer]

I think that this works as designed - if exception handler tells us to return 500, we will return it.
The exception handler should be aware of JAX-RS jakarta.ws.rs.WebApplicationException that are used to return specific responses as part of control flow, and should not consider these to be internal server errors.

[AshwinPrabhuB]

This is a definite change in behaviour between H3 and H4. The same exception mapper that is disrupting Health routing in H4 was not fouling in H3.

[FelTap23]

But why is it not able to identify metrics and health paths?

[shad0w-jo4n]

Quite a strange behavior. For example, if I want to make a custom response for a 404 error, then I will have to get UriInfo from the context and check the path in it for compliance with the path of metrics, OpenAPI, etc.

It looks terrible:

var path = uriInfo.getPath();

if ((path.equals("metrics") || path.startsWith("openapi")) && e instanceof NotFoundException web) {
    return web.getResponse();
}