Blazor Server keep-alive & reconnection issues

[garrettlondon1]

Is there an existing issue for this?

• No

Is your feature request related to a problem? Please describe the problem.

SignalR connection has a Keep-Alive (default 15 seconds) which is the criteria for the reconnection modal appearing.

This means if a button is clicked on Web, and the keep-alive just triggered 1 second ago, when the client disconnects they're waiting 14 seconds for the reconnection modal..

No DOM updates can be communicated over SignalR and user can continue clicking buttons

The worst part of this is:

• Dom events build up and are transmitted to the server on reconnection

This is a very poor user experience for users who expect feedback from buttons/actions that cannot be communicated from the server to the client via the broken socket connection.

• There are additional consequences for the server side

The developer has no way of intercepting any client side event within this potential 14 seconds of UI interaction

The reconnection modal is fine, you can customize the appearance pretty nicely. It's just about the developer meeting the reconnection process when it happens, not 15 seconds after it happens

Repro steps

• Create a Blazor Server app and run it
• Browse to the app with the browser dev tools open
• On the networking tab in the browser dev tools set the network throttling to offline
• Try to use the app

Expected result: The disconnected UI is displayed almost immediately prior to or in response to any UI interactions
Actual result: The disconnected UI isn't displayed and clicking on the UI elements does nothing for about 15sec

Describe the solution you'd like

Have not thought about the implications of this, but depending on client side interactions, we could reset the keep-alive and ping on every @onclick handler (or any other condition) and throttle it every 2-3 seconds to prevent continuous pinging of the server if a user spam clicks?

It seems silly to prevent the .1% or less times that the user will get disconnected and experience UI hanging, but it is such a significant issue (if reconnect modal doesn't properly appear), that I feel it's warranted.

Additional context

Yes state being lost, and ability to resume circuits is important, but I think this is a bigger fundamental problem. One experience of this will pretty much turn you off of the framework for any enterprise web app, and send you the SPA way.

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

[MackinnonBuck]

Thanks for reaching out! We've moved this issue to the backlog for now to gather additional feedback from the community about whether this is a change that should be made.

[surayya-MS]

Related #48675

[halter73]

Have not thought about the implications of this, but depending on client side interactions, we could reset the keep-alive and ping on every @OnClick handler (or any other condition) and throttle it every 2-3 seconds to prevent continuous pinging of the server if a user spam clicks?

I'm pretty sure the SignalR Core clients already reset the keep-alive timeout every time they receive any message from the server, not just a keep-alive. I also think the server only bothers sending a keep alive if there are no other messages sent within the KeepAliveInterval. Correct me if I'm wrong @BrennanConroy.

What happens if you lower the KeepAliveInterval and ClientTimeoutInterval?

[garrettlondon1]

@halter73 I don't think it's about the keep-alive on the server. It's really the client side keep-alive that matters, how often the client pings the server. Blazor Server you can specify the HubOptions in Startup for the server, and modify the blazor server.js startup to change on the client as seen in #48675. The client needs to know if it's disconnected in order to show the Reconnection modal defined in _Host.cshtml, which lives on the client.

I lowered the client side keep-alive to 1 second, which easily detects disconnects super quickly. The problem is, no matter what you do, even if you do nothing, you will spam my server every 1 second.. although It's working nicely.. The Client Timeout interval is when the "Disconnected" modal appears, so I think it's fine to leave at any value really, since the main problem I'm trying to solve here is immediately show "Reconnecting" when client disconnects, not when the next keep-alive (15 seconds by default) is executed.

[garrettlondon1]

Related #32113

[garrettlondon1]

https://learn.microsoft.com/en-us/aspnet/core/blazor/host-and-deploy/server?view=aspnetcore-7.0

The KeepAliveInterval isn't directly related to the reconnection UI appearing. The Keep-Alive interval doesn't necessarily need to be changed. If the reconnection UI appearance issue is due to timeouts, the ClientTimeoutInterval and HandshakeTimeout can be increased and the Keep-Alive interval can remain the same. The important consideration is that if you change the Keep-Alive interval, make sure that the client timeout value is at least double the value of the Keep-Alive interval and that the Keep-Alive interval on the client matches the server setting.

Can the docs provide more clarity about how the "Keep-Alive isn't directly related to the reconnection UI appearing"?

[alexyakunin]

I don't think this happens exactly as you describe - as far as I understand,

• Blazor reacts to websocket disconnection
• TCP keep-alive (as far as I understand, the KeepAlive is exactly this) is just one of ways to determine for TCP/IP stack that the connection is dead. Others include no ACK to regular packets, network connection failure, etc.

The idea to send keep-alive to detect the disconnection faster seem meaningless, because TCP implies that any transmission requires ACK, not only keep-alive packet. And it's easy to conclude that such a transmission happens when you click a button - to deliver the event notification to server.

[alexyakunin]

What might be the real cause is SignalR reconnection - I am not sure about all the details, but it might be masking the fact that websocket connection is dead & it tries to reconnect while behaving like nothing happened.

[garrettlondon1]

I've been going through src/Components/Web.JS/src/Platform/Circuits/DefaultReconnectionHandler.ts to try and get a better understanding.. but no luck.

The Keep-Alive interval (keepAliveIntervalInMilliseconds or KeepAliveInterval) isn't directly related to the reconnection UI appearing. The Keep-Alive interval doesn't necessarily need to be changed. If the reconnection UI appearance issue is due to timeouts, the server timeout can be increased and the Keep-Alive interval can remain the same. The important consideration is that if you change the Keep-Alive interval, make sure that the timeout value is at least double the value of the Keep-Alive interval and that the Keep-Alive interval on the server matches the client setting.

@danroth27 @MackinnonBuck @jongalloway Terms like "isn't directly related" or "doesn't necessarily need to be changed".. fairly confusing for technical documentation.

Imagine you're building a CRUD app and the websocket drops when your user clicks "Create sensitive record", nothing happens, no reconnection modal.. Your user will continue to click that button dozens of times and once the connection re-establishes, now you have flooded your API, and the user is even more frightened.

From a framework perspective server-side blazor needs to be able to offer the application developer the choice to immediately notify the user of the reconnecting process, or leave the default settings. Note: only have experience with Blazor Server deployed on App Service using Azure SignalR

@alexyakunin

but it might be masking the fact that websocket connection is dead & it tries to reconnect while behaving like nothing happened.

If what you are saying here is true: the websocket connection has severed, and it's trying in the background without triggering the Reconnecting modal, why delay the Reconnecting modal?

[danroth27]

Terms like "isn't directly related" or "doesn't necessarily need to be changed".. fairly confusing for technical documentation.

@garrettlondon1 Agreed! To help get this fixed in the docs, could you please report an issue for the specific doc page by clicking the link at the bottom of the doc page?