Baggage propagation doesn't seem to work when Exception captured in middleware

I’m updating NuGet Trends with the latest JavaScript (Angular) and .NET SDKs.

One of the things since the last update is the introduction of this feature: https://changelog.getsentry.com/announcements/connect-session-replays-to-backend-errors

Unfortunately it doesn’t seem to work:

I throw an exception from my C# controller, but only the Frontend error shows on the Replay:

Using the Replay Network details to capture the baggage header, I can confirm the JS SDK is sending it:

Value (from replay):

sentry-environment=local,sentry-transaction=%2F,sentry-public_key=85a592e835c64ca3a97d93776c12e947,sentry-trace_id=20b4f41dc98f49e2b25b5f88ffae1901,sentry-sample_rate=1,sentry-replay_id=8f9bf18820be4450b62868dc460be8d8

The exception captured by the .NET SDK included the envelope header:

[23:11:08 DBG] Envelope 'c0736a5e8f594176a65a9c0129b05cdd' successfully sent. Content: {"sdk":{"name":"sentry.dotnet","version":"3.33.1"},"event_id":"c0736a5e8f594176a65a9c0129b05cdd","sent_at":"2023-06-23T03:11:08.488511+00:00"}
{"type":"event","length":19132}
{"modules":{"System.Private.CoreLib":"7.0.0.0",.....

Note that replay_id isn’t included.

Investigation

The PR that added support here is:

• https://github.com/getsentry/sentry-dotnet/pull/2332

Note that we look for a Span from an exception to support the case where a transaction is closed when unwinding the stack due to an exception bubbling up. Which is the case in ASP.NET Core where the root middleware captures the exception but further in the call chain we start/stop transactions:

https://github.com/getsentry/sentry-dotnet/blob/060480e1dfb42ca2044a8445c1d8e71b84b23f73/src/Sentry/Internal/Hub.cs#L275-L290

But on this PR adding support for DSC on exceptions, we don’t consider the lookup, and only expect the transaction on the scope:

https://github.com/getsentry/sentry-dotnet/blob/060480e1dfb42ca2044a8445c1d8e71b84b23f73/src/Sentry/Internal/Hub.cs#L163-L166

I tried to validate that by not throwing from the controller, but instead just calling CaptureMessage. With a transaction on the scope, thing should work. That wasn’t the case.

The exception included the DSC details, but no replay_id:

[23:44:21 DBG] Envelope '60ce0fe4d9294f27acbb429d3a7c858f' successfully sent. Content: {"sdk":{"name":"sentry.dotnet","version":"3.33.1"},"event_id":"60ce0fe4d9294f27acbb429d3a7c858f","trace":{"trace_id":"0c6188d56e9e49ffba45e31e5b697b3c","public_key":"57331596a25b4c3da49750b292299e09","sample_rate":"1","release":"NuGetTrends.Web@1.0.0\u002Ba678a0d59db0bcef71578b7c341c10c48ac5c80f","environment":"development","transaction":"GET api/package/history/{id}"},"sent_at":"2023-06-23T03:44:21.916599+00:00"}

[jamescrosswell]

k, I think that fixed it:

[jamescrosswell]

OK, I think I’ve worked out what’s going on. We have two bits of middleware: SentryMiddleware and SentryTracingMiddleware. When the later captures an exception, it finishes the transaction:

                else if (status == SpanStatus.Ok)
                {
                    transaction.Finish(exception);
                }
                else
                {
                    transaction.Finish(exception, status);
                }

Internally, that Finish method binds the transaction (which basically stores it in the Hub’s internal ExceptionToSpanMap). SentryTracingMiddleware then throws the exception again.

Next the global exception handler in the SentryMiddleware gets activated. That creates an event from the exception and then calls hub.CaptureEvent… which eventually ultimately executes Hub.CaptureEventInternal.

At this point, since the transaction has finished, the current scope no longer has a transaction associated with it and so when we try to read the transaction off the scope and the DSC off the transaction, it’s nulls all the way down.

            // When a transaction is present, copy its DSC to the event.
            var transaction = actualScope.Transaction as TransactionTracer;
            evt.DynamicSamplingContext = transaction?.DynamicSamplingContext;

Luckily, our SentryTracingMiddleware stored a map between the exception and the original span/transaction in the ExceptionToSpanMap and so we can get this information from there instead.

I’ll put together a unit test and a fix.