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

Incorrect HTTP status recorded when using custom exception handler #924

Open
danielksb opened this issue Jan 24, 2025 · 4 comments
Open

Comments

@danielksb
Copy link

danielksb commented Jan 24, 2025

Expected Behavior

When running a Micronaut server with a custom exception handler that maps specific exceptions to HTTP statuses other than 500, the metrics incorrectly record the status as 500. This issue arises when using Micronaut versions 4.7.x and above, whereas the expected behavior was observed in version 4.6.x.

Given

  • an exception "DemoException"
  • an endpoint "GET /api/error" which triggers the exception
  • a CustomExceptionHandler implementing ExceptionHandler<DemoException, HttpResponse> responding with http status 400

Upon invoking the endpoint that triggers the DemoException, the expected metric should be:

http_server_requests_seconds_count{exception="none",method="GET",status="400",uri="/api/error"} 1

Actual Behaviour

Instead of recording the expected status, the metric is:

http_server_requests_seconds_count{exception="DemoException",method="GET",status="500",uri="/api/error"} 1

Steps To Reproduce

Please see the example in the repository below.

Environment Information

  • Previous Version: This behavior was functioning correctly in Micronaut version 4.6.x.
  • Current Version: The issue began occurring with the release of Micronaut version 4.7.x and continues in subsequent versions.

Example Application

https://github.com/danielksb/micronaut-demo-micrometer-bug

Version

4.7.x

@SushmaReddyLoka
Copy link

SushmaReddyLoka commented Feb 10, 2025

We are also seeing similar issue on 4.7.5 version, we are emitting bad request status code 400 from the exception handler but the metrics is capturing it as 500.
Till the fix is available is there any way to work around this problem, as we are heavily relying on the metrics.

@SaiYashasvi9
Copy link

Is there any work around available?

@SushmaReddyLoka
Copy link

@graemerocher , @jameskleeh @sdelamo can you provider your inputs on this issue.

@graemerocher
Copy link
Contributor

I guess you can disable the built-in default metrics and write your own version of

in the meantime

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants