Weird interaction between `UseProblemDetails` and Serilog's `UseSerilogRequestLogging`

First, 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!

[alexdresko]

I wasn’t able to last week 😦 but Imma take a stab at it this morning.

[khellang]

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:

1. Call Rethrow<Exception>() on the problem details options to make sure exceptions bubble up to the Serilog middleware after being converted to a response.
2. Change the Serilog middleware to respect the actual response status code