sentry-dotnet
sentry-dotnet copied to clipboard
`fatal` Logs from `Microsoft.AspNetCore.Hosting.Diagnostics` should be marked as unhandled
Problem Statement
When Hosting crashes, it uses M.E.L to log the fatal message. The SDK is able to capture that, but doesn't flag the exception with any mechanism or handled:false which Sentry uses to tell apart 'crashes' from user handled errors:
https://sentry.io/share/issue/d0770225d93e4e5dba8fb75caa95d03f/
Solution Brainstorm
Suggestion: In M.E.L, special case fatal level + category (logger) such as Microsoft.AspNetCore.Hosting.Diagnostics to mark exceptions as handled:false.
Alternatively we could consider all level=fatal as handled:false, but I'm not sure of the consequences
level=fatal as handled:false
my instinct says to use this approach, and deal with the consequences as they come up
can u think of an cases where " level=fatal as handled:false" would be the wrong approach?
i will investigate if the "fatal is handled:false" should be applied in other places
An idea came up to understand impact: Get the number of events with level=fatal and non handled:no to understand impact
so, as i understand this, the intent is to add a new IObserver<KeyValuePair<string, object?>> that handles Microsoft.AspNetCore Diagnostics events?
ok looking into this more. isnt this what AspNetCoreExceptionProcessor does?
internal class AspNetCoreExceptionProcessor : ISentryEventExceptionProcessor
{
public void Process(Exception exception, SentryEvent @event)
{
// Mark events collected from the exception handler middlewares via logging as unhandled
if (@event.Logger is "Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddleware" or "Microsoft.AspNetCore.Diagnostics.DeveloperExceptionPageMiddleware")
{
if (@event.SentryExceptions != null)
{
foreach (var ex in @event.SentryExceptions)
{
ex.Mechanism = new Mechanism
{
Type = "ExceptionHandlerMiddleware",
Handled = false
};
}
}
}
}
}
isnt this what
AspNetCoreExceptionProcessordoes?
It would appear so. Though I don't see any reference to fatal.
We need a better repro of the problem to move this forward.