Enhance error context by including log call site in .NET SDK

[dalnoki]

Problem Statement

Currently, when an error is reported using the .NET Sentry SDK, the stack trace included in the exception reflects only the point at which the exception was thrown. However, it does not include the location (call site) where the error was logged or reported to Sentry.

Solution Brainstorm

No response

[linear[bot]]

NET-404 Enhance error context by including log call site in .NET SDK

[Flash0ver]

see Linear issue for more context

[jamescrosswell]

I don't think we can do this without changes to the event payloads.

For statically typed compiled languages like C#, at runtime we don't have the source code... for AOT compiled applications we might not even have the IL bytecode. So the only way to determine the log call site is to find the corresponding frame and then symbolicate this. That needs the debug symbols, which will typically have been uploaded to Sentry (or some other public symbol server).

To get this working, I think another field would have to be added to the event envelope: "logCallSiteFrame" or something like that... and then the Sentry server would need to symbolicate that and use source maps to work out what the actual call site was. Or possibly we could capture a stack trace for the call site as well (and symbolicate the whole stack trace, rather than just a single frame).

Either way, I don't believe we can implement this in the .NET SDK without supporting changes in both the Sentry protocol and ingest.

[Flash0ver]

If this isn't a feature that we add to the platform and SDKs (soon), user code could extract this information from compiled caller information and set these as Additional Data via SetExtra, or, when intended to be indexed and searchable, as custom Tags:

internal static SentryId CaptureException(Exception exception,
    [CallerMemberName] string callerMemberName = "",
    [CallerFilePath] string callerFilePath = "",
    [CallerLineNumber] int callerLineNumber = 0)
{
    return SentrySdk.CaptureException(exception, (Scope scope) =>
    {
        // as Additional Data
        scope.SetExtra("caller_member_name", callerMemberName);
        scope.SetExtra("caller_file_path", callerFilePath);
        scope.SetExtra("caller_line_number", callerLineNumber);
        // or as custom Tags
        scope.SetTag("caller_member_name", callerMemberName);
        scope.SetTag("caller_file_path", callerFilePath);
        scope.SetTag("caller_line_number", callerLineNumber.ToString());
    });
}

and then call this method instead

-SentrySdk.CaptureException(exception);
+MyExceptionHelpers.CaptureException(exception);

[jamescrosswell]

Perhaps we can add this in the next major release of the SDK (it would involve changing the signatures for various public methods).

[Flash0ver]

Could be solved with an Interceptor (C# only), which went GA in .NET SDK 9.0.200, so it requires Roslyn 4.13.0: analyzers\dotnet\roslyn4.13\cs\compilerextension.dll

See https://github.com/dotnet/roslyn/blob/main/docs/features/interceptors.md. See also https://github.com/getsentry/sentry-dotnet/issues/4321#issuecomment-3380388724.

[Flash0ver]

Brand new Code Attributes.