[Review agent] Calibrate Blazor DI scope teardown IJSObjectReference disposal findings (#69970, #70340)

Open
  • Is something wrong?
#70,360 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
45/100
Issue type
Documentation
Clarity
Clearly specified
Activity status
Active
Tech stack
csharp, javascript
Domain
backend, documentation

Research direction

Start with docs/BlazorComponentsGuidance.md and .github/agents/review-candidate-verifier.agent.md, then check the cited Storage.cs, CookieStore.cs, Window.cs, and Screen.cs conventions and the JSObjectReference.DisposeAsync behavior. Document the scope teardown behavior for Interactive Server and WebAssembly, and update verifier guidance to check sibling patterns, exception handling, and whether disposal is reachable outside teardown. Done when the guidance covers both findings and the cited review cases.

Written by the indexing model from the issue text.

Description

area-blazor area-infrastructure
Is there an existing issue for this?
  • I have searched the existing issues
Is your feature request related to a problem? Please describe the problem.

Across two Microsoft.AspNetCore.Components.Platform PRs (#69970 and #70340), review passes produced P2 lifecycle findings around IJSObjectReference disposal during Blazor DI scope teardown (IInternalAsyncDisposal.InternalDisposeAsync) without establishing a reachable production trigger or accounting for existing repository conventions:

  1. Non-waiting pending acquisition at DI scope disposal (#69970 Screen.cs:103 and #70340 Window.cs:88):

    • In Screen.cs (#69970) and Window.cs (#70340), GetReferenceAsync() caches _jsRuntime.GetValueAsync<IJSObjectReference>(...).AsTask(), and InternalDisposeAsync() intentionally only disposes _referenceTask.Result when _referenceTask is { IsCompletedSuccessfully: true } with the comment: 
      // Don't wait for a pending acquisition. It could hold up scope disposal until the JS interop timeout.
if (_referenceTask is { IsCompletedSuccessfully: true } referenceTask)
{
    await referenceTask.Result.DisposeAsync().ConfigureAwait(false);
}
    • Review arms (gpt-5.6-sol and gpt-6.1-sol on #69970; gpt-6.1-sol on #70340) flagged a P2 leak if the scope is disposed while GetReferenceAsync() is still in flight and the JS reference arrives afterward.
    • While the source-level mechanism is conditionally possible if an IJSRuntime completes GetValueAsync after InternalDisposeAsync checks _referenceTask.IsCompletedSuccessfully (and JSCallbackFactory.ImportModuleAsync in #70340 explicitly disposes a late-arriving module to satisfy BrowserJSRuntime unit tests that call ServiceProvider.DisposeAsync() while holding "import"), this exact non-waiting pattern is already established in Storage.cs:111-115 and CookieStore.cs:179-183 on main.
    • Furthermore, Window.AddEventListenerAsync already throws ObjectDisposedException after await GetReferenceAsync() (Window.cs:70), and as the author explained in #69970 comment 4489650667, Blazor DI scope disposal in supported hosts runs during Interactive Server circuit teardown (where inbound interop completion and disposal are serialized on the circuit/renderer dispatcher) or WebAssembly page unload — so a P2 production leak claim is not established without a concrete supported-host trigger.

  2. Exception propagation during IJSObjectReference.DisposeAsync at DI scope disposal (#70340 Window.cs:159, CCR comment 4489112121):

    • Separately from the pending-acquisition pattern above, CCR comment 4489112121 (and corroborating review notes) claimed that await referenceTask.Result.DisposeAsync() in Window.InternalDisposeAsync() could throw JSDisconnectedException or TaskCanceledException during circuit teardown and skip subsequent feature cleanup.
    • As the author noted in #70340 comment 4489969683, CircuitHost.DisposeAsync calls JSRuntime.MarkPermanentlyDisconnected() before disposing the DI scope (preventing new outbound calls from being sent), and JSObjectReference.DisposeAsync already suppresses JSDisconnectedException (since #64773).
Describe the solution you'd like
  1. Calibrate Blazor Components / JSInterop review guidance (docs/BlazorComponentsGuidance.md and/or .github/agents/review-candidate-verifier.agent.md):
    • Document the Blazor DI scope teardown contract for scoped JS interop projections (Window, Screen, Storage, CookieStore):
      • In Interactive Server, CircuitHost marks JSRuntime permanently disconnected before scope disposal runs, inbound completions are coordinated through the circuit/renderer dispatcher, and JSObjectReference.DisposeAsync already ignores JSDisconnectedException.
      • In WebAssembly, the DI scope for browser platform services lives until page unload.
      • Non-waiting disposal of a lazy Task<IJSObjectReference> (if (_referenceTask is { IsCompletedSuccessfully: true })) that matches existing Storage/CookieStore conventions is intentional so scope disposal cannot hang on a pending JS interop call, and should not be elevated as a P2 blocking production leak unless a reachable non-teardown disposal path is established in the PR.
  2. Require review-candidate-verifier to check existing sibling conventions and JSObjectReference.DisposeAsync exception contracts:
    • Before keeping a P2 disposal-leak or JSDisconnectedException propagation candidate on an IJSObjectReference, verify whether JSObjectReference.DisposeAsync already suppresses the claimed exception and whether the disposal path is reachable in a supported host outside circuit/page teardown.
Additional context
  • Tracked under #70231.
  • Evidence PRs:
    • #69970 (src/Components/Platform/src/Screen.cs:103, author explanation in 4489650667)
    • #70340 (src/Components/Platform/src/Window.cs:88 and Window.cs:159, author explanation in 4489969683)
Dominant language
C#
Stars
38.5k
Forks
11.6k
Avg merge
3d 1h
Merged PRs (30d)
289

Getting set up

Open in Codespaces

Starts the project's dev container in your browser, under your own GitHub account.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from dotnet/aspnetcore

All issues in dotnet/aspnetcore

Similar issues

More C# issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.