Blazor Server circuit retention vs. client reconnection timeout for flaky networks

Direct resolution

Likely explanation: the client‑side reconnection window and the server’s DisconnectedCircuitRetentionPeriod act as two independent gates. If the client’s timeout exceeds the server retention window, the circuit is already gone, and reconnection attempts become a no‑op that only consumes SignalR thread budget.

Confirmed fact: the Blazor framework does not expose a per‑circuit memory counter; memory usage scales with component tree depth, injected services, and any active timers or threads held in the circuit.

1. Set a concrete DisconnectedCircuitRetentionPeriod on the server (e.g., 30 seconds) and record the initial process memory.
2. Configure the client Blazor.start({ reconnectionOptions: { timeout: 25000 } }) so the timeout is a few seconds under the server period, preventing wasted reconnection after circuit discard.
3. Enable DiagnosticSource logging for Microsoft.AspNetCore.Blazor.Server.Circuit and capture CircuitCreated, CircuitDisconnected, and CircuitDisposed events; use the logs to correlate elapsed time with memory snapshots.
4. In a test environment, simulate flaky conditions (Chrome DevTools Network throttling, traffic shaping) and force a disconnect; observe the client’s reconnection attempts via the browser console and verify that reconnection stops once the elapsed time exceeds the configured retention period.
5. After each scenario, take a memory profile (dotMemory or PerfView) to compute the heap difference between circuit creation and disposal, providing an empirical per‑circuit memory footprint.

To finalize the DisconnectedCircuitMaxRetained value and reconnection timeout, I need one diagnostic detail: approximately how many concurrent disconnected circuits your app typically holds in production, and whether any components hold transient timers or scoped services that inflate per‑circuit memory.