.NET Core - Logging Fatal Errors

SDKs
1

Hi All.

I am currently integrating Sentry into a .NET Core 3 app - it’s set up and working and errors are correctly being logged :partying_face:

When an error is encountered I am using UseExceptionHandler("/Home/Error") to redirect the user to a nicer error page which basically says something went wrong. To assist in debugging, we also include a link straight back to the Sentry issue so that one of our helpdesk team can connect to that users PC, go straight to the Sentry issue caused by the error they just had and look at what went wrong.

In order to do this we use the LastEventId method, and this works well most of the time. However sometimes it seems like the Sentry issue isn’t actually created until AFTER the Home/Error page is loaded (meaning that LastEventId returns as 0 and obviously it’s then too late to give any context to the error page). This seems to be when a fatal error occurs (a contrived example is below)

image
image1065×290 24 KB

(As I say the error IS captured in both instances by Sentry but in the first case only after the page has loaded)

In theory we could manually create a Sentry event from the Error controller that we link back to but this seems a bit counter intuitive as much of the useful logging info will be missing and we will be “doubling up” on the log.

Could anyone advise how I can get Sentry to create the event (and hence have a LastEventId) before the .NET Exception Handler takes over. Any help would be very much appreciated!!

Many thanks :slight_smile:

2

That happens because the middleware pipeline works in a way that the UseExceptionHandler runs before the Sentry SDK captures the unhandled Exception. So the page renders before Sentry gets a hold of the exception.

If we moved the UseExceptionHandler earlier in the pipeline, since Sentry anyway rethrows any exception without affecting the original stacktrace, it should work for it to capture the event. But using Sentry.LastEventId will not work since the scope pushed inside SentryMiddleware would be gone by the time UseExceptionHandler getst the exception in its catch block.

We could add the SentryId generated for that event in a HttpContext so that you could read it from the error page though.

Feel free to raise an issue on the SDK GitHub repository: GitHub - getsentry/sentry-dotnet: Sentry SDK for .NET

We’d be glad to merge a PR adding this feature.

3

Hi Bruno,

Many thanks for your reply, as suggested I have raised this in GitHub :slight_smile:

Many thanks,
Louis