We’re using a Blazor Server architecture with Lamar as the DI container, registering certain services as scoped to maintain one instance per Blazor circuit.
This setup generally works well. However, in rare cases, users may lose connection or close the browser, which closes the Blazor circuit and disposes of the scoped services. If some actions are in progress, services like dynamically resolved Mediator preprocessors may throw a System.ObjectDisposedException due to timing issues.
This issue is challenging to troubleshoot and not easily solved by re-evaluating service registrations. It also occurs with objects like DotNetObjectReference and in other layers. While scoped services seem appropriate in certain scenarios (singleton isn’t viable, and transient is wasteful due to per-circuit state), I haven’t found much documentation on best practices.
For example, the CircuitRegistry class (https://github.com/dotnet/aspnetcore/blob/97c6f0df0d7b643dd5bac6f8a8641bd16738d2c5/src/Components/Server/src/Circuits/CircuitRegistry.cs#L37) mentions that detecting disconnections isn’t an exact science. Similarly, the JSDisconnectedException (https://learn.microsoft.com/en-us/aspnet/core/blazor/javascript-interoperability/?view=aspnetcore-8.0&preserve-view=true) suggests catching and optionally logging the exception without further intervention.
Are there best practices for handling these issues, or are most systems designed differently to avoid them?
As this seems like a common occurence (somene loosing the connection or just closing during a workflow), I'm not sure if either:
- We missdesigned something here (using scoped services)
- Most people just ignore these errors?