Is there documentation on the available SentryEvent fields when BeforeSend is called? (C# SDK)?

I’m using the C# SDK with ASP.Net Core 2.2 (upgrading soon). I’m trying to take advantage of the BeforeSend configuration in SentryOptions to try and downgrade or filter out specific events coming through the ILogger interface but I’m finding that some of these fields (notably Message, for sure) are not set at BeforeSend and appear to be relying on a template instead, despite statements that indicate that BeforeSend should be the last step in the pipeline.

Is there documentation on what fields can be trusted to be set on the SentryEvent when BeforeSend is called? I’ve spent a good amount of time on this already, dove into the code for the SDK (both the main repo and the protocols one), and done some searches but I haven’t come up with a conclusive answer yet.

At the time BeforeSend is called, the event is complete. The SDK doesn’t add anyting to the event after calling it.

One thing to note is that Sentry (the server), when processing the event, normalizes it. So when you download the JSON from the event page, it can include some fields that were added as a result of this processing.

In the ASP.NET Core integration we leverage the structured logging support of the framework. So instead of adding SentryEvent.Message which is a string, we use another property that allows us to pass the template, as well as the final message.
This helps with grouping since now Sentry knows that User {userId} logged on can be grouped together as opposed to User 1 and User 2 … etc.

This happens https://github.com/getsentry/sentry-dotnet/blob/1aaa3e609162b660148d51ec58973ff8e13eb791/src/Sentry.Extensions.Logging/SentryLogger.cs#L74-L78 for the ASP.NET Core integration. Please note the property name LogEntry will change on the next major release.

Worth noting Sentry is working on better support for data scrubbing in the backend (or via a Relay process that you can host yourself, if you want).

Ok. I looked at the other property on LogEntry and that will suffice. Luckily I’m not trying to scrub in this case, I actually have to filter and reduce the priority on some logged messages from a third-party library. Shy of building my own intermediary ILogger, the message text was the fastest approach and if LogEntry or the this library change I can take that cost on later.

Thanks!