Server-Sent events (SSE) or Long Polling issue with SignalR service deployed in Service Fabric

Question

Hello,

I deployed a SignalR Service (.NET 6.0) in a Service Fabric cluster (version - 10.1.2175.9590), and the frontend is a React application (microsoft/signalr: 8.0.0). This allows us to run a few long-running reports by consuming SignalR service from the frontend application. By default, all reports run through WebSocket. Still, if WebSocket is blocked, the system automatically switches to SSE, but handshaking or connection fails for SSE or Long Polling.

While connecting SignalR in the development environment (locally) using SSE, the reports run fine. But once SignalR API is deployed in the Azure Service Fabric cluster, it throws an error while consuming from the frontend application - "Error: Server returned handshake error: Handshake was canceled," and ultimately SignalR connection id is not generated.

Locally, SSE successfully connects -

Need assistance in resolving the above issue. Any help or suggestions would be appreciated.

Thanks a lot.

Kind regards, Deb

Answer 1

Hello Ghosh, Debasis,

Welcome to the Microsoft Q&A and thank you for posting your questions here.

Problem

I understand that you are encountering an issue (Server-Sent events (SSE) or Long Polling) with SignalR service deploy to Azure Service Fabric.

Solution

This is a known or common issue related to SignalR and Azure Service Fabric.

Some of the things you can do to resolve the issue, the provided links will give you more detail steps and references for further reading:

• The error you're encountering might be due to Cross-Origin Resource Sharing (CORS) restrictions. Since your service and client are hosted on different servers, ensure that you've correctly configured CORS policies in your ASP.NET Core SignalR application. So,
  • Make sure that the CORS settings allow calls from the domain where your React frontend is hosted. You can configure CORS in your ASP.NET Core application by specifying allowed origins, headers, and methods.
  • If you've already configured CORS and the issue persists, double-check the configuration to ensure its correctly applied in your Service Fabric environment
• Azure Service Fabric uses a reverse proxy to route requests to your services. Sometimes, this proxy can interfere with WebSocket connections. When running on a multi-node Service Fabric cluster, ensure that your SignalR service is running on all nodes of the same node type. Load balancers distribute traffic across nodes, so having consistent service availability on all nodes is crucial. Expose the SignalR service directly (similar to how you did for the frontend) to avoid any reverse proxy issues.
• Look for unhandled exceptions in your SignalR service. Check logs or run the app in debug mode to identify any issues at the server level. The HTTP 500 error you're seeing indicates an internal server error, which could be related to exceptions in your code. https://stackoverflow.com/questions/54023999/signalr-issue-on-azure-service-fabric-error-during-websocket-handshake.
• Use Azure SignalR Service diagnostics to troubleshoot further. In the Azure Portal, navigate to your SignalR app, go to Diagnose and solve problems, and review resource usage and availability/performance metrics. https://learn.microsoft.com/en-us/answers/questions/1282501/get-404-during-websocket-handshake-with-azure-sign
• If hosting the SignalR service as an App Service worked, consider using that approach. However, if you need to stick with Service Fabric, ensure that the reverse proxy and load balancer configurations are correctly set up. https://stackoverflow.com/questions/54023999/signalr-issue-on-azure-service-fabric-error-during-websocket-handshake.

Accept Answer

I hope this is helpful! Do not hesitate to let me know if you have any other questions.

** Please don't forget to close up the thread here by upvoting and accept it as an answer if it is helpful ** so that others in the community facing similar issues can easily find the solution.

Best Regards,

Sina Salam