azure-signalr: Failed to connect to '(Primary)https://.service.signalr.net', will retry after the back off period.

Describe the bug

After a full day of successful operation, two of my three environments started throwing the following exception in multitude with my SignalR instance:

Failed to connect to '(Primary)https://<name>.service.signalr.net', will retry after the back off period. Error detail: Unable to connect to the remote server. A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond..

To Reproduce

Not sure if I could if I wanted to. It just started happening and would not stop.

Some notes:

  • I was able to access https://<name>.service.signalr.net from my local environment without issue.
  • Creating a new SignalR instance and pointing my connection string to that instance worked. Maybe a DNS issue?

Exceptions (if any)

Message:

Unable to connect to the remote server. A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.

Further technical details

  • Your Azure SignalR SDK version 1.4.0
  • Your Server ASPNETCORE version or Assembly version of Microsoft.AspNetCore.SignalR net6.0
  • Your SignalR Client SDK version 6.0.7

About this issue

  • Original URL
  • State: closed
  • Created 2 years ago
  • Comments: 17 (8 by maintainers)

Most upvoted comments

looks like there is a bug when reading from config… try using Azure:SignalR:ApplicationName:

so your production client traffic might be routed to your staging app server, which means they are not isolated.

I mean from Azure SignalR’s perspective of view, your production client traffic might be routed to your staging hub server. You can consider Azure SignalR as a proxy that routes messages from the client to your multiple server instances.

Also please consider my experience here where I had everything simply “just work” with Blazor Server-side but now here after upgrading to Azure SignalR there are tons of bells/whistles/configurations

This is a nice catch, @Jialin shall we consider applying the Environment variable as the ApplicationName for Blazor apps (but sounds a breaking change), or maybe add some documentation for such a scenario?