When server-side Blazor cannot reconnect to the server, it displays a message offering a link to "reload" the page. But if the user clicks it, nothing happens (except it logs an error to the JavaScript console saying Error: Cannot send data if the connection is not in the 'Connected' State.). This is bad because it directly breaks an important end-user experience.

The broken functionality was introduced here and here. The new code mutates the DOM to add new "reload" links, but doesn't attach any event handlers for those links, so instead of triggering a reload they attempt to trigger regular navigation (which can't work because we're not connected, and would not be what we want to do even if we could do it).

Note that this is meant to be covered by CTI tests - we have an issue https://github.com/aspnet/Tooling-ManualTests/issues/522 tracking the need to add/update CTI coverage for it, but that remains open and incomplete.

Fixing it

To fix this, we need to make some fairly small targeted tweaks to the logic in DefaultReconnectDisplay.ts. This is a very safe change to make, since no other part of the system builds on it. The bug we have currently is pretty bad so I definitely think we should deal with this for 3.0.

Since the reconnection logic now contains multiple code paths representing different failure types, this would be hard to test even through manual CTI tests, since forcing these different scenarios would be very tricky. I would recommend we stop distinguishing different types of failures and treat them all the same so it's realistic to test. It won't make any difference to the end-user experience, since we were intending to produce virtually identical UX for all failure types. Simplifying this logic also makes the change even safer.