Open davidfowl opened 10 months ago
Thanks for contacting us.
We're moving this issue to the .NET 9 Planning
milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.
Should we do this tracing in all directions? Client to server and server to client?
Yes please. Bidirectional tracing is useful in scenario's like IoT devices with local intelligent hubs plus cloud (a project I am working on). Or like in this chat app example trace, 2 app instances connected to the cloud backend with SignalR. It is helpful to see the true end2end flow and timings.
Still planning to do this in 9.
The activity source "Microsoft.AspNetCore.SignalR.Server"
can now be listened to on server applications.
Lots of progress on this in .NET 9. Moving to 10 for the rest.
Actually, this might be worth reconsidering a bit more thoughtfully to decide which parts to prioritize. Un-milestoning for now (cc @BrennanConroy @JamesNK)
Today SignalR invocations do not have any activity associated with them. We currently piggy-back on the default ASP.NET Core activity and it's not great for invocations over the websocket. We should add an activity following the semantic conventions for rpc.
Open questions:
cc @BrennanConroy