Consider adding SignalR connection ID to the trace

[paulomorgado]

It would be useful to correlate traces from the same connection.

Maybe with tag signalr.connection.id.

[nenoNaninu]

This feature was supported from v1.6.0. Try it!

[paulomorgado]

Unfortunatelly, I need to stay on v1.4.0, because I need LTS dependencies and v1.5.0 and v1.6.0 forces STS dependencies.

Can you point on the code where it's being added?

[nenoNaninu]

TFM of AspNetCore.SignalR.OpenTelemetry is only .NET 8(LTS).

https://www.nuget.org/packages/AspNetCore.SignalR.OpenTelemetry/1.6.0#dependencies-body-tab

.NET 8 is also supported by OpenTelemetry.Api v1.11.1, on which AspNetCore.SignalR.OpenTelemetry depends. AspNetCore.SignalR.OpenTelemetry v1.6.0 should work fine with .NET 8, and it does on my local machine.

https://www.nuget.org/packages/OpenTelemetry.Api/1.11.1#dependencies-body-tab

[paulomorgado]

Thanks!

It's not about the runtime supportability, but the library supportability. Components used by OpenTelemetry have breaking changes in v9 and may cause runtime errors. Also, v8 libraires are supported up until November 10, 2026 and v9 libraries are supported only up until May 12, 2026.

Adding to that, the user might have a mandate to use LTS dependencies only.

[nenoNaninu]

You may not want to upgrade System.Xxx packages from v8 to v9. But what about the support period of OpenTelemetry packages? OpenTelemetry does not provide a support period for the same as System.Xxx packages. Not only new features but also bug fixes are released as new versions and are not backported. If you use OSS, you should pay the cost of upgrading to the latest version.

[paulomorgado]

I know!

But a user can always upgrade if not limited by the package owner, but not downgrade.

@DamianEdwards addressing this issue on ASP.NET Community Standup - .NET Aspire Q&A