Currently, when code breaks and causes a 500 error for clients, the client gets the appropriate response that omits the error details. This is what you want, since clients don't need to know about exception details for security reasons, but these exceptions also seem to be completely silenced for developers, so you don't know what's going on.
It turns out ErrorHandlerFilterAttribute is causing this. Ideally the errors should be logged through an ILogger so logging infrastructure can still follow these appropriately.
In my code I currently just injected an ILogger<ErrorHandlerFilterAttribute> and logged all exceptions (4xx exceptions as warnings, since it's the client's fault, and 5xx errors as errors), which also automatically makes them show up in the console.
this should be resolved in the last release with the new error handler setup. going to close but if you're still seeing something that's concerning around this feel free to call it out and i'll take a look!
Currently, when code breaks and causes a 500 error for clients, the client gets the appropriate response that omits the error details. This is what you want, since clients don't need to know about exception details for security reasons, but these exceptions also seem to be completely silenced for developers, so you don't know what's going on.
It turns out
ErrorHandlerFilterAttribute
is causing this. Ideally the errors should be logged through anILogger
so logging infrastructure can still follow these appropriately.In my code I currently just injected an
ILogger<ErrorHandlerFilterAttribute>
and logged all exceptions (4xx exceptions as warnings, since it's the client's fault, and 5xx errors as errors), which also automatically makes them show up in the console.