Better reconnection logic for Blazor Server

[konradbartecki]

Summary

Currently there is an issue with Blazor Server-side where it is not reconnecting circuits automatically and losing connection especially on mobile browsers.

See #23340 #26985

Motivation and goals

• Automatically reload page on Reconnection attempt to the circuit was rejected by the server. This may indicate that the associated state is no longer available on the server.
• Automatically reload page on mobile browsers that lost connection (probably due to browser tab being suspended), see Blazor Server Side. JS doesn't start after a long downtime on mobile browsers. #23340 Investigate behavior of Blazor Server on mobile when switching apps #26985

In scope

• Automatically refresh the page when circuit was rejected
• Add onReconnectionFailed event
• onReconnectionFailed could be used to automatically refresh the page instead of asking user to do that manually like in a screenshot shown below
• Change DefaultReconnectionHandler.attemptPeriodicReconnection to try to reconnect first and then delay, instead of delaying first and then trying to reconnect. (Possibly could fix Blazor Server Side. JS doesn't start after a long downtime on mobile browsers. #23340 Investigate behavior of Blazor Server on mobile when switching apps #26985)

Out of scope

Risks / unknowns

• Difficult to test on mobile browsers

Examples

DefaultReconnectionHandler.ts

 async attemptPeriodicReconnection(options: ReconnectionOptions) {
    for (let i = 0; i < options.maxRetries; i++) {
      this.reconnectDisplay.update(i + 1);

      const delayDuration = i == 0 && options.retryIntervalMilliseconds > ReconnectionProcess.MaximumFirstRetryInterval
                            ? ReconnectionProcess.MaximumFirstRetryInterval
                            : options.retryIntervalMilliseconds;
      this.logger.log(LogLevel.Debug, `Reconnecting in ${delayDuration}`);
      await this.delay(delayDuration);
      //code..
      //try { reconnect() }
      
     //instead of delaying 3000ms first and trying to reconnect later
     //we could try to reconnect first and delay afterwards
     //this could possibly fix reconnection on suspended mobile browsers

Example onReconnectionFailed event default implementation

    Blazor.defaultReconnectionHandler.onReconnectionFailed = function (d) {
        document.location.reload(); 
    }

I can take care of the implementation of this task.

Related issues

#23340
#26985
#40721
#30344
#41791

[konradbartecki]

I checked a debug release of my app and my assumptions were correct

On mobile the browser tab is getting awaken from the sleep
first we wait the default time of 3000ms
then we try to reconnect
then this attempt immediately fails because associated state is no longer available on the server (which makes sense)

Solution:

• Reorganize code to try to reconnect first, delay afterwards
• Reload the page after rejection as it is a better default.

WIP PR: #32122

[javiercn]

@konradbartecki thanks for contacting us.

We have a feature in the works to better support this scenario in 6.0. You can check it here

We recommend you upvote that issue instead so that we can keep track of the interest as well as the issue covering general improvements for server-side Blazor here

[javiercn]

I'm going to close this issue in favor of the two issues mentioned in my previous comment.

Nevermind, I see that there is a PR. We will evaluate it and see if we want to take it.

[ghost]

Thanks for contacting us.

We're moving this issue to the Next sprint planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[ghost]

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.

[HybridSolutions]

Found some interesting results about this issue. Please check it here

[vindberg]

@konradbartecki is this something we can implement as a quick fix for our Server Blazor applications until the "real" solution is possible (now pushed to V8).

[konradbartecki]

@vindberg Yes, I'm running let's say a custom fork, of dotnet/blazor with this fix only, so you could do it manually by:

• Downloading dotnet/blazor source
• Applying fixes locally
• Building a dist version of blazor.server.js
• Then in _Host.cshtml I just include my own blazor.server.js fork with this fix
  <script src="/blazor.server.js"></script>

See PR: #32122

[konradbartecki]

Related:

• APIs for components to persist state across circuits manually #30344
• Blazor Server-side Loses Connection Upon Extended Phone Lock #41791

[vindberg]

Thanks for getting back to me. I see there are some comments from @SteveSandersonMS about the delay and checks (two times ?). Have you included those?

I was hoping for an easier solution that didn't involve a custom fork of the repo. Im not sure MS knows how big an issue this is for Blazor adoption.

[konradbartecki]

Workaround: #30344 (comment)

[Ghevi]

I'm trying this on a Blazor project with .Net 8 but the onConnectionDown function is never called.
This code works in .Net 7 where the first script src is _framework/blazor.server.js instead of _framework/blazor.web.js
Am i missing something?
Well it seems that using _framework/blazor.server.js works even in .Net 8 and everything seems fine, but i'm not using webassembly or auto rendering mode. The documentation says to use _framework/blazor.web.js in .Net 8...

<script src="_framework/blazor.web.js" autostart="false"></script>
<script>
        Blazor.start({
            reconnectionHandler: {
                onConnectionDown: () => {
                    console.log("connection down")
                },
                onConnectionUp: () => {
                    console.log("connection up")
                },
            },
        });
</script>

[TheXenocide]

It's possible this has been addressed in newer versions as I haven't focused much on reconnect logic recently, but one thing we ran into that presented challenges with reconnection was that the disposal of the scoped service provider was bound to the request lifetime, rather than the circuit lifetime, which results in ObjectDisposedExceptions when reconnecting to a state which has disposable injected services. Ideally, the circuit would keep the scoped service provider undisposed until the circuit is disposed.

[danroth27]

One UX design issue to consider here (if it hasn't been already mentioned) is to have a reconnection UI that accounts for only part of the page being unresponsive. Currently we overlay the entire page, but it could be that only a single component on the page is using interactive server rendering.

[Johnhersh]

One UX design issue to consider here (if it hasn't been already mentioned) is to have a reconnection UI that accounts for only part of the page being unresponsive. Currently we overlay the entire page, but it could be that only a single component on the page is using interactive server rendering.

I would love to see that!

[rhires]

It might be fun to start working this out as part of a debug session. It's sometimes painful when I'm trying to debug something and the browser loses the connection, which is surprising since it's a known connection and all that's happened is that I've hit a breakpoint but it takes "too long" for the connection to get refreshed, so it just hits that "1 of 8" thing. Like, how does it not know that I'm debugging? Can it figure out how it lost the connection? Or is that a stupid question? It would be useful for it "know" that I'm debugging so that it won't lose the connection.

[eschimmel]

@rhires The problem with debugging is indeed that it might cause a timeout. I partly solved this by adding log statements on the methods. When a method is entered, left and when an exception occurs. Adding these statements manually is tedious. I use the Metalama framework to have it done automatically. Not so long ago, I wrote a few articles about logging and the use of Aspect Oriented Programming and the Metalama framewrok. You can read the articles on my website at: https://byte217.com

[mkArtakMSFT]

This has been completed as part of #55721
Another set of improvements in this area is going to be handled separately as part of #56678 in the future.