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

Abierto
  • ¿Algo no está bien?
#70,360 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
45/100
Tipo de issue
Documentación
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
csharp, javascript
Área
backend, documentation

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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)
Lenguaje dominante
C#
Estrellas
38.5k
Forks
11.6k
Merge medio
3 d 1 h
PR fusionados (30 d)
289

Preparar el entorno

Abrir en Codespaces

Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de dotnet/aspnetcore

Todos los issues de dotnet/aspnetcore

Issues similares

Más issues de C#

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.