Closed LouisMilesRH closed 2 years ago
I'll mark this as a bug even.
It should be possible to get the SentryId
of an event when the Error Page loads. That means we need to make sure things happen in the right order there. Or perhaps it might require a second middleware since we do need one as early as possible to anyway capture exceptions in the middleware pipeline.
Another approach to investigate is a way to capture the exception as part of that UseExceptionHandler
if it exposes some hook.
Please mark the type framework used:
Please mark the type of the runtime used:
[ ] .NET Framework
[ ] Mono
[x ] .NET Core
Version:
Please mark the NuGet packages used:
[ x] Sentry
[ ] Sentry.Serilog
[ ] Sentry.NLog
[ ] Sentry.Log4Net
[ ] Sentry.Extensions.Logging
[x ] Sentry.AspNetCore
Version:
As per discussion on the Forum here https://forum.sentry.io/t/net-core-logging-fatal-errors/9956/2
When using UseExceptionHandler in .NetCore, Sentry SDK captures the errors after the handler has fired. This means that it is impossible to give any reference back to the Sentry error (for example with Last Event Id) in the error page loaded by the Event Handler.
Bruno suggested that one solution to this would be to add the SentryId into the HttpContext so that it could be read from the error page and when required, a link then to the Sentry debugging info could be generated.
Further details are included in the above link but hopefully this summary is enough to get an idea of this suggestion.