Customized SocketsHttpHandler should not break distributed tracing

[samsp-msft]

dotnet/runtime#31261

[cijothomas]

Is this issue created just to track the issue from runtime? Or any other workaround planned here? I wonder if it is even possible to have any workaround at all.

[Tratcher]

It's only for tracking so far. No workaround has been proposed.

[cijothomas]

It's only for tracking so far. No workaround has been proposed.

Thanks. We were following up internally and was wondering if anyone found workarounds.

[karelz]

Discussion with @samsp-msft: This is not solvable in 5.0 timeframe of .NET Core - hence removing the label ".NET runtime schedule".
YARP 1.0.0 should try to implement the workaround we recommend on main issue (keeping it in 1.0.0 milestone).

[Tratcher]

@karelz would this be a good one for @MihaZupan?

[jmezach]

We just ran into this issue which is a bit of a bummer because we were kinda expecting this to work out of the box. We have New Relic set up to monitor our environment but it is unable to correlate the requests going into YARP and onwards to the downstream service.

Is there something we can help out with?

[Tratcher]

If you'd like to experiment with the workarounds for YARP by all means. E.g. you could try copying the DiagnosticsHandler into YARP and wiring it up.

[MihaZupan]

Fixed by #456

We exposed a new class ActivityPropagationHandler for injecting tracing headers based on the current activity.

It is used by the HttpInvoker factory by default, unless disabled by setting PropagateActivityContext to false explicitly.