You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe the problem.
Describe the solution you'd like
Azure SignalR team recently has some customers requesting for “reconnect” related metrics to evaluate the impact to their customers when the connections are interrupted by service maintenance events, for example, the latency between the disconnect and reconnect, the success rate of a connect attempt.
However, from the service side, it is currently a little bit hard to correlate the reconnects if the hubconnection restarts because the connectionId is changed. We currently try with the same “userId” and “IP”. I am wondering if it is valuable to append some “correlationid” to a HubConnection in the client SDK by default, so that we could track the lifetime of the HubConnection when it re-starts? It could also be used to correlate the negotiate request to the app server with the negotiate/connect request to the SignalR service.
Additional context
No response
The text was updated successfully, but these errors were encountered:
Is there an existing issue for this?
Is your feature request related to a problem? Please describe the problem.
Describe the solution you'd like
Azure SignalR team recently has some customers requesting for “reconnect” related metrics to evaluate the impact to their customers when the connections are interrupted by service maintenance events, for example, the latency between the disconnect and reconnect, the success rate of a connect attempt.
However, from the service side, it is currently a little bit hard to correlate the reconnects if the hubconnection restarts because the connectionId is changed. We currently try with the same “userId” and “IP”. I am wondering if it is valuable to append some “correlationid” to a HubConnection in the client SDK by default, so that we could track the lifetime of the HubConnection when it re-starts? It could also be used to correlate the negotiate request to the app server with the negotiate/connect request to the SignalR service.
Additional context
No response
The text was updated successfully, but these errors were encountered: