SpanProcessor.OnEnd never gets called if FilterHttpRequestMessage returns false

[jamescrosswell]

The Sentry OpenTelemetry integration uses a custom SpanProcessor that listens for OnStart and OnEnd events to create a SentrySpan for each OpenTelemetry Activity.

For the most part, this works well. However if HttpClientInstrumentationOptions.FilterHttpRequestMessage is configured, any traces for outgoing HttpClient requests that get filtered by that delgate trigger SpanProcessor.OnStart but never trigger SpanProcessor.OnEnd... which is of course problematic.

A couple of questions:

1. Is this by design, or is it a bug?
2. If it's by design, is there any way we can detect if/when Activities get filtered by HttpClientInstrumentationOptions.FilterHttpRequestMessage?

[cijothomas]

This maybe tricky.. If recording (isalldatarequested flag) is false, then processors won't be invoked, so this is by-design. But it is questionable whether the filter should flip the recording decision...

If your goal is to listen to all activity start/stop calls, irrespective of filtering/other things, then a workaround would be to setup an ActivityListener yourself - this will be called no matter what the filtering is done!

Also - why are you modelling this as a processor? Can you use an exporter to convert spans to sentryspans? (Ignore this, if you have a reason for this approach. I am curious as to why!)

[jamescrosswell]

Thanks @cijothomas, I think I've found a workaround... it's a bit fiddly but seems to work.

Re the decision to use a processor, largely this was because I took over Sentry's OpenTelemetry integration when it was already about 50% built... so I just went with the flow. I'm not sure if this could be redesigned to use an exporter - I suspect it might be difficult. Sentry does crash reporting as well as Tracing... and when we catch unhandled exceptions, these get associated with the active span (so you can navigate between your traces and associated crash reports). Sentry also has some custom integrations with stuff that doesn't use OpenTelemetry and we create spans/traces etc. for those... currently using Sentry's Tracing API. Eventually, I think the plan is to move all instrumentation to OpenTelemetry but that will be a bit of a journey and so, for the time, Sentry's Tracing API hangs all of these things together.