Reload the browser when the circuit ID is unknown

[rynowak]

If I launch a components app with dotnet watch run - the reconnection feature doesn't ever seem to do its thing.

I can retry, and it will successfully connect (see console output) - but it never updates the UI.

My guess is that this happens because the circuit is gone - it's a new process after all. We should see if we can improve this for inner loopness, and figure out a better experience by default for the case where the circuit is gone.

[rynowak]

@javiercn in case he has cool thoughts

[javiercn]

Yeah, my guess is the same as yours. The only option at that point is to F5 the app. We should inform the client that the circuit is gone and provide some button on the UI to refresh the page as at that point the app is gone.

[javiercn]

I think this not only applies to developer inner loop. In the future we might want to free up resources in case the app is idle for a while, at that point there should be some integration so that developers can take that into account and provide a good experience.

For example, something like

The application has been inactive for too long so we have ended your current session. 
Click here to refresh the application.

[danroth27]

We discussed this and we think it would help that if the circuit ID is unknown we reload the page.

[gingters]

I think that behavior should be configurable. In development mode a reload is fine and most likely expected.

In production, there could be a lot of issues (i.e. server node accidentally or gracefully restarted) and that might involve trying to persist some sort of session state when the server gracefully shuts down and trying to restore that state when a new circuit starts.

Also, the user might want to be informed when he should expect an application reload and possibly loss of data.

[uabarahona]

What I found:

dotnet watch reconnection

This works:

1. Create a new blazor server app
2. Run it with dotnet watch run
3. Change some files
4. The restart and reconnection of the server works fine

Restart the server manually

1.- Manually restart the server by killing the process and then dotnet watch run again
2.- Old pages will try to reconnect until they notice the server is no longer the same and will display the following:

So, unless I am missing something, this is already working, right?

[captainsafia]

@barahonajmc Thanks for testing it out! Can you confirm what version you validated this on?

[uabarahona]

@captainsafia oh I forget that, it was on .NET 5 RC1

[BieleckiLtd]

Here is how the user experience looks in my case.

User loads page, works with the app, perhaps fills the form halfway through. They go for a snack and when they come back they see that their work is gone as the only thing they can do is to refresh the browser. Great for the banking app, but my users complain.

Disabling idle timeout would help but app pool can still recycle at any time unless this is also disabled. Corporate IT is not happy to change any of the application pool settings anyway. Similarly with my hobby stuff - online hosting providers are saying to go and buy VPS if I need such customization.

tl;dr
I know this is a long shot but are there any plans to improve user experience with blazor after the application restart? Maybe persist user session state in the browser?

[konradbartecki]

I actually implemented the exact scenario where this is configurable with default of reload page on circuit rejected
See: #32122

[TanayParikh]

Related:

• Enhance Blazor.reconnect to state whether failures are due to circuit not existing so we can auto-reload page #44669
• [Blazor] Better diagnostics for Blazor server #43513
• [Blazor] Disconnect alternative proposal #39409
• APIs for components to persist state across circuits manually #30344
• Ability to monitor circuit activity #30287

[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.

[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.

[danroth27]

We're planning to address this as part of #9256 #32113

[aryehsilver]

We're planning to address this as part of #9256

Which is this issue but has now been closed?!?

[danroth27]

Dah! Sorry! The correct tracking issue is #32113.