Reconnection enhancements

[SteveSandersonMS]

Following on from work done for #11999, here are some improvements to reconnection that we'd like to make:

• Make the "retry" button show some acknowledgement when you click it
  • For example, disable it for 1 second following the click
  • If the manually-initiated retry fails, then change the dialog text to say "Reconnection failed. Try reloading the page if you're unable to reconnect.". It will still have the two options, "[Retry]" and "[Reload page]".
• Explicitly detect connection failures due to "server says unknown circuit ID", and in those cases, auto-reload the whole page since we know reconnection isn't realistically going to work.
  • We need to avoid infinite refresh loops, e.g., put a flag in sessionStorage to say we did an auto-reload, clear that flag the next time a connection is successful, and don't do an auto-reload any time the flag is still there.

The latter one would give the biggest benefit, as it's useful not only in production but also in development. This is the flow that happens each time you change your code and rebuild the application.

[vertonghenb]

This will also solve the problem for iOS webclip "PWA's", which cannot be refreshed by nature.

[NTaylorMullen]

Explicitly detect connection failures due to "server says unknown circuit ID", and in those cases, auto-reload the whole page since we know reconnection isn't realistically going to work.

• We need to avoid infinite refresh loops, e.g., put a flag in sessionStorage to say we did an auto-reload, clear that flag the next time a connection is successful, and don't do an auto-reload any time the flag is still there.

@SteveSandersonMS / @rynowak this seems like the wrong solution to me. If something bad happens on the client or server and we then start auto-refreshing the page the user will lose all logs/console output from the page due to the refresh.

A good example of this being a poor experience for developers is if a user is doing a specific workflow that breaks the server or client and you enter into this failed reconnection state -> page auto refreshes -> you're now back into a "valid" state;, all the logs for how you got into the original invalid state are now gone unless you manually captured them during the brief time that reconnection was occuring.

A better solution would be to:

1. Document having your own reconnect display where a failed invocation can be used to force a refresh on the users behalf.
2. Have a flag that turns this feature on or off.

I lean towards 1 primarily because a user having their own reconnect display will be a must for any proper Blazor server side site. I'm less enthused by 2 because having a rando flag that you turn on-off depending on if you're in production or not (in JS) would add to the complexity.

Thoughts?

[NTaylorMullen]

Another route would be to pass additional information to failed which could indicate that reconnection wont be possible. At which point we could provide the dialog to reload the page (instead of retry)

[NTaylorMullen]

Given the lack of responses here I'm going to just pick something that feels the most "right" to me.

I plan to expand ReconnectDisplay to have a rejected method on it:

export interface ReconnectDisplay {
  show(): void;
  hide(): void;
  failed(): void;
  rejected(): void;
}

And our default implementation of ReconnectDisplay's rejected will provide a nice error message Could not reconnect to the server. <a href>Reload</a> the page to restore functionality.

If you don't like this suggestion please let me know.