Prevent JS interop after circuit disposal. Fixes #32808

[SteveSandersonMS]

See more details about the problem at #32808 (comment). In summary, any component that attempts JS interop during disposal (for example, <Virtualize>) would hang until the JS call times out, preventing cleanup of any scoped resources for that period.

This PR changes how JS interop works after a circuit has begun disposal (which typically means the user has closed their browser tab or navigated away):

• Before: JS interop calls would not get any response from the browser, so they'd just hang for a minute and eventually time out with an exception
• After: JS interop calls will throw immediately using a new exception type (JSDisconnectedException)

I think we can regard this as not a breaking change because the calls would have eventually thrown anyway, and still do. It now just completes this process faster. The advantages of this change are:

1. DI scopes no longer live for an extra minute before cleanup in this case (e.g., when you have an active <Virtualize> component and the user closes the tab). They now clean up immediately.
2. Component authors who want to treat this as not-an-error now have a specific exception type they can catch and suppress. This is now done inside Virtualize so it won't even get logged as an error. This makes sense in cases where you were only trying to do JS interop to clean up browser-side state, and obviously don't care about that if the browser is already gone.

If we wanted, we could consider more dramatic options like:

• Not treating JS interop calls as failing with exceptions if the browser is disconnected. I think that's a bad idea because (1) it would be hugely breaking, and (2) semantically it doesn't make sense - we won't know if the developer actually requires some info back from the browser or wants to know for sure whether a void call was received and completed.
• Auto-suppressing JSDisconnectedException entirely from logs. I think that's a bad idea because it likely prevents developers from discovering that one was even happening. And then if their disposal logic looked like DoJsCleanUp(); DoDotNetCleanUp();, they would not realise that the DoDotNetCleanUp part never executes. I think developers need to know this is an error and it's up to them to try/catch if they want to control how it's handled.

[mkArtakMSFT]

Thanks @SteveSandersonMS!

[ghost]

Thank you for submitting this for API review. This will be reviewed by @dotnet/aspnet-api-review at the next meeting of the ASP.NET Core API Review group. Please ensure you take a look at the API review process documentation and ensure that:

• The PR contains changes to the reference-assembly that describe the API change. Or, you have included a snippet of reference-assembly-style code that illustrates the API change.
• The PR describes the impact to users, both positive (useful new APIs) and negative (breaking changes).
• Someone is assigned to "champion" this change in the meeting, and they understand the impact and design of the change.

[javiercn]

Changes look great!

Do we need to do anything for calls that might already be in-flight?

[SteveSandersonMS]

Do we need to do anything for calls that might already be in-flight?

I considered it, but didn't think it was desirable because:

(1) it's not required to solve any known problem (the call will eventually time out anyway, and isn't keeping the circuit open)
(2) it's more likely to affect people with existing code in ways we haven't predicted
(3) it's trickier to implement since we would have to change a bunch of things about how the timeouts get triggered or get surfaced as exceptions

Overall since it's not required to solve the current problem here, I wasn't inclined to expand the scope of the solution. We could do it in the future if a sufficient need arises.

[pos777]

Hello @SteveSandersonMS,

I am using the sample from the #32808 (comment) issue with .NET v5.0.6.
If I open the 'Virtualize test' page, then close it, and wait for a while, I get the TaskCanceledException:

Assume, I'm developing a custom Virtualize component. Currently, I have to write something like this to avoid this exception:

public async ValueTask DisposeAsync()
{
    try
    {
        if (_selfReference != null)
        {
            await _jsRuntime.InvokeVoidAsync($"{JsFunctionsPrefix}.dispose", _selfReference);
        }
    }
    catch (**TaskCanceledException**)
    {
        // If the browser is gone, we don't need it to clean up any browser-side state
    }
}

Will this code break under .NET 6?
Since the JSDisconnectedException is a new class and it is not available in .NET 5, should I create two versions of the custom Virtualize component? One with the TaskCanceledException processing for .NET 5, and the other with the JSDisconnectedException processing for .NET 6.

Thanks,
Ilya

[ghost]

Hi @pos777. It looks like you just commented on a closed PR. The team will most probably miss it. If you'd like to bring something important up to their attention, consider filing a new issue and add enough details to build context.