[release/8.0] [Blazor] Defer enhanced component updates until reconnection circuit completes

[MackinnonBuck]

Defer enhanced component updates until reconnection circuit completes

Ensures that enhanced updates to interactive server components get deferred until the circuit is reconnected.

Description

This PR includes two changes:

1. Takes circuit "connected-ness" into account when determining if enhanced component updates can be applied
2. Waits until any given root component's disposal gets acknowledged by .NET before the browser stops tracking it for SSR updates

Fixes #51082

Customer Impact

This change impacts Blazor Web scenarios where interactive server components exist on the page.

With this fix, it's more likely that a customer with an unstable connection will be able to continue using the app without refreshing the page. In particular:

1. If a developer creates a custom, less intrusive reconnection dialog that allows the user to keep interacting with the app, a user-induced page navigation during reconnection won't bring the app to an unusable state
2. If the user quickly navigates between pages while the circuit is unstable, there won't be console errors caused by attempting to interactively update a component that was removed from the page

Regression?

• Yes
• No

These fixes only affect "Blazor Web" scenarios, which are new in .NET 8.

Risk

• High
• Medium
• Low

This is a moderately-sized change. However, we have existing automated tests that verify the scenarios that this code is likely to impact, and we've added new tests to help ensure that these fixes introduce the above stability improvements.

Verification

• Manual (required)
• Automated

Packaging changes reviewed?

• Yes
• No
• N/A

[ghost]

Hi @MackinnonBuck. Please make sure you've updated the PR description to use the Shiproom Template. Also, make sure this PR is not marked as a draft and is ready-to-merge.

To learn more about how to prepare a servicing PR click here.

[SteveSandersonMS]

I think I understand the main ideas here and it seems reasonable to me.

It still seems as if state could be left hanging in edge cases (e.g., if the EndUpdateRootComponents message gets dropped, the client may think a root still exists but the server does not) but since that's only used for client-side cleanup that's not catastrophic.

[ghost]

Hi @MackinnonBuck. This PR was just approved to be included in the upcoming servicing release. Somebody from the @dotnet/aspnet-build team will get it merged when the branches are open. Until then, please make sure all the CI checks pass and the PR is reviewed.

[MackinnonBuck]

It still seems as if state could be left hanging in edge cases (e.g., if the EndUpdateRootComponents message gets dropped, the client may think a root still exists but the server does not) but since that's only used for client-side cleanup that's not catastrophic.

Yep, this is definitely something that can happen. In the future, we could consider a mechanism to detect if the circuit disconnects while a set of root component operations are being applied and somehow react to that.