-
Notifications
You must be signed in to change notification settings - Fork 10.4k
Blazor Server Add Console Warning if Long Polling #36764
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Blazor Server Add Console Warning if Long Polling #36764
Conversation
} | ||
} | ||
|
||
// Check if the connection is established using the long polling transport, | ||
// using the `features.inherentKeepAlive` property only present with long polling. | ||
if ((connection as any).connection.features.inherentKeepAlive) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Spoke with @BrennanConroy regarding best means to identify if a connection is Long Polling
. He suggested relying on this property implicitly (instead of explicitly adding a marker to the SignalR HttpTransport). Will be adding a E2E test that validates this behavior.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should log a warning, not an error, since the app will continue working.
// Check if the connection is established using the long polling transport, | ||
// using the `features.inherentKeepAlive` property only present with long polling. | ||
if ((connection as any).connection.features.inherentKeepAlive) { | ||
logger.log(LogLevel.Error, 'Failed to connect via WebSockets, using the Long Polling fallback transport. This may be due to a VPN or proxy blocking the connection. To troubleshoot this, visit https://aka.ms/blazor-server-using-fallback-long-polling.'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
https://aka.ms/blazor-server-using-fallback-long-polling will point to a new docs page which discusses common pitfalls and troubleshooting steps to ensure WebSockets are utilized (ie. enabled on IIS, enabled on azure portal, etc.). May just end up extending https://docs.microsoft.com/en-us/aspnet/core/blazor/host-and-deploy/server?view=aspnetcore-6.0#signalr-configuration.
Regarding the server-side logging of long polling, SignalR already takes care of this for us via;
Other than that, there isn't an explicit way for us to recognize the connection type in the hub, but I believe this may be sufficient for tracking purposes. |
📆 with E2E tests, should be good to merge now. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great!
/backport to release/6.0 |
Started backporting to release/6.0: https://github.com/dotnet/aspnetcore/actions/runs/1266548760 |
@TanayParikh an error occurred while backporting to release/6.0, please check the run log for details! Error: @TanayParikh is not a repo collaborator, backporting is not allowed. |
* Blazor Server Add Console Error if Long Polling * E2E Testing * Fix tests * Update Boot.Server.ts
We reverted enforcing WebSocket based transports via #36656.
This PR adds back some of those error messages, along with a new error message specifically mentioning that Long Polling is being utilized.
TODO: add E2E tests.Fixes: #36817