SignalR KeepAlive Interval not being honored - Blazor Server

[garrettlondon1]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

https://learn.microsoft.com/en-us/aspnet/core/blazor/fundamentals/signalr?view=aspnetcore-7.0#configure-signalr-timeouts-and-keep-alive-on-the-client

Documentation says:

• When changing the values of the server timeout (ServerTimeout) or the Keep-Alive interval (KeepAliveInterval:

The server timeout should be at least double the value assigned to the Keep-Alive interval.
The Keep-Alive interval should be less than or equal to half the value assigned to the server timeout

When specifying the Keep-Alive interval as 5000ms and Server Timeout as 30000ms, the Keep-Alive still defaults to 15 seconds

Expected Behavior

Keep-Alive interval is honored. Currently if a user disconnects from SignalR or has a connection issue, when a button is pressed in Server-side blazor application the UI hangs for 15 seconds before displaying the reconnection modal.

One solution using the Keep-Alive should be to send more frequent pings so that it is quicker to tell when a client is not receiving DOM updates.

Steps To Reproduce

<script src="_framework/blazor.{HOSTING MODEL}.js" autostart="false"></script>
<script>
  Blazor.start({
    configureSignalR: function (builder) {
      let c = builder.build();
      c.serverTimeoutInMilliseconds = 30000;
      c.keepAliveIntervalInMilliseconds = 5000;
      builder.build = () => {
        return c;
      };
    }
  });
</script>

Using the script above if you inspect the WS connection in JS console, you will see pings of 15 seconds, regardless of Keep-Alive

Exceptions (if any)

No response

.NET Version

7.0.32

Anything else?

No response

[BrennanConroy]

That code snippet part of the docs shouldn't be showing for <=7.0, it's new in 8.0. @guardrex

[guardrex]

That was supposed to be the workaround for 7.0 or earlier. The new approach replacing it for 8.0+ is ...

<script src="_framework/blazor.{HOSTING MODEL}.js" autostart="false"></script>
<script>
  Blazor.start({
    configureSignalR: function (builder) {
      builder.withServerTimeout(30000).withKeepAliveInterval(15000);
    }
  });
</script>

Cross-refs:

• https://learn.microsoft.com/en-us/aspnet/core/blazor/fundamentals/signalr?view=aspnetcore-8.0#configure-signalr-timeouts-and-keep-alive-on-the-client
• Server timeout and Keep Alive interval config AspNetCore.Docs#29297

I don't think @surayya-MS necessarily has any info on it at the time of the 8.0 content review, given that the workaround was placed years ago before her arrival. I'll need to dig back and see who sent it over/approved it for publication.

If it doesn't work at all (and perhaps it never did), then we'll need to pull all of our guidance on controlling both of those for versions earlier than 8.0.

I'll get back to you here by EOD with what I find out.

[garrettlondon1]

Thanks all,

I think from a business perspective...

Once in a while, maybe .1% of times, a user will click a button, and nothing will happen for 5-10 seconds, then UI will finally figure itself out. I would imagine, if the websocket is disconnected, the reconnection modal appears, but it doesnt! That's why I tried decreasing the keep-alive interval.

I would rather the reconnection modal appear more frequently if the client loses connection to the server, instead of the UI not responding when a button is clicked and there is an expectation for something to happen.

Ultimately, people end up clicking again, or even worse, refreshing. I don't care if SignalR gets disconnected, and my clients do not mind the reconnection modal.

Is there a way to make the reconnection modal appear within like 1 second of the button getting clicked and not receiving a DOM update from the server?

[guardrex]

Originally, there was an incorrect bit of code shown for the workaround, which was my fault [CORRECTION: The incorrect code came from the PU.] However, we fixed that. Here's Javier saying that that code ☝️ should work ...

#18840 (comment)

... and then @surayya-MS is commenting further on it a little further down that issue saying in more detail why it should work at ...

#18840 (comment)

What I'll ultimately need to know is if that really is 😈 NOT a Thing™ 😈. In our chats about it (including earlier when I put a bad workaround up the first place), there was no other way to set those values in 7.0 or earlier other than the workaround. If it really doesn't work, then I'll need to strip it out of our docs and say that changing those values is unsupported (prior to our new approach for 8.0+).

[guardrex]

... and just to flesh out why it was orginally wrong, it was this at first ...

<script src="_framework/blazor.{HOSTING MODEL}.js" autostart="false"></script>
<script>
  Blazor.start({
    configureSignalR: function (builder) {
      builder.serverTimeoutInMilliseconds = 30000;
      builder.keepAliveIntervalInMilliseconds = 15000;
    }
});
</script>

... which came from @javiercn at ...

#42778 (comment)

... but like I said ... it's fixed in the current version of the doc ... IF it's a thing at all for 7.0 or earlier. 😄

[BrennanConroy]

Oh nvm, serverTimeoutInMilliseconds and keepAliveIntervalInMilliseconds are the new APIs. I misread the docs for 7.0 😆

Using the script above if you inspect the WS connection in JS console, you will see pings of 15 seconds, regardless of Keep-Alive

Pings from the client or the server?

[garrettlondon1]

I see pings from the server happening every 15 seconds, I'm not seeing anything from the client except acks from the server pings

Do i need to add:

services.AddSignalR(e =>
                {
                    e.MaximumReceiveMessageSize = 102400000;
                    e.KeepAliveInterval = TimeSpan.FromSeconds(5);
                }

also?

[BrennanConroy]

https://learn.microsoft.com/en-us/aspnet/core/signalr/configuration?view=aspnetcore-7.0&tabs=dotnet#configure-server-options-6

[garrettlondon1]

The values should match for client & server correct?

[garrettlondon1]

Also, is there an issue with putting the keep-alive super low? Like 3 seconds? Why is the default 15? I'm guessing because of mobile situations for Blazor Server?

[garrettlondon1]

I have configured keep-alive on the client and the server to be 3 seconds, 5 seconds, etc.. Unable to get it working, still see 15 seconds..

Could you share a boilerplate project I can run to see? I am also using Azure SignalR Service if that matters

[BrennanConroy]

Also, is there an issue with putting the keep-alive super low? Like 3 seconds?

More bandwidth and higher latency connections will be closed more often.

The values should match for client & server correct?

They don't need to, although if you set the timeout to a value lower than the keep alive you'll have issues (and we generally recommend the timeout is twice the keep alive interval).

[garrettlondon1]

More bandwidth and higher latency connections will be closed more often.

Won't the keep alive just trigger the reconnection modal if latency is high? The server timeout will still be 30 seconds, I just want the client to be aware that it's disconnected from SignalR sooner than the 15 second default, so the UI does not hang. My users are only in the United States, latency is very low.