Weird interaction between `UseProblemDetails` and Serilog's `UseSerilogRequestLogging`
See original GitHub issueFirst, I want to say that I’m not sure if this is a problem with UseProblemDetails
or UseSerilogRequestLogging
. But I’m pretty sure I’ve got a few new gray hairs trying to figure this out and I need to create an issue somewhere. If this is deemed to be a Serilog problem, I’ll take this discussion over there.
Plus, @khellang is a great guy and is always responsive to issues… So Imma start where I’m comfortable. 😃
In short, with both UseProblemDetails
and UseSerilogRequestLogging
in place, my API properly converts exceptions into, say, HTTP 404 problem details as configured:
That’s good.
However, when with UseSerilogRequestLogging
in place, that same request shows up as HTTP 500 in Serilog’s output (I’m using Seq):
The stack seems to show that there’s some implicit interaction between the two middlewares. UseProblemDetails
seems to be the initiator, but obviously UseSerilogRequestLogging
is what triggers the unwanted change. If I remove UseSerilogRequestLogging
, everything works as expected, sans whatever UseSerilogRequestLogging
does. I only have that line of code in the application because that’s what the instructions say to do. I don’t know what UseSerilogRequestLogging
actually does.
This post may be of some help – sentence “Because the UseSerilogRequestLogging() middleware runs in the request handling pipeline outside of ASP.NET Core MVC, the request completion event doesn’t include MVC-specific details like ActionId or ActionName by default.” seems suspect. But this is all well outside my realm.
Here’s a repro if you need it. You’ll need Seq to view the output (or I can change the repro to log to a file). Simply [un]commenting UseSerilogRequestLogging
affects the output. When the site is running, just hit http://localhost:6215/api/test/d in your browser to trigger the exception. There are a few more API methods in the controller for testing related interactions.
It doesn’t seem like the order of the two middlewares matters, less I messed that test up.
I hope all of that makes sense. I’ll make myself readily available to answer questions.
Thank you SO much for your time!
Issue Analytics
- State:
- Created 3 years ago
- Comments:9 (5 by maintainers)
I wasn’t able to last week 😦 but Imma take a stab at it this morning.
However, if you do want exceptions to be logged by Serilog (which I expect you might), you still need to have Serilog as the very first middleware in the pipeline, but with two additional changes:
Rethrow<Exception>()
on the problem details options to make sure exceptions bubble up to the Serilog middleware after being converted to a response.