Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

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

See original GitHub issue

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

Issue Analytics

State:
Created a year ago
Comments:16 (7 by maintainers)

Top GitHub Comments

1reaction

vicancycommented, Aug 2, 2022

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

1reaction

vicancycommented, Aug 2, 2022

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?