[Blazor] Adds support for persisting and restoring disconnected circuits from storage #62259

javiercn · 2025-06-05T16:04:37Z

Details to be added. There are some missing things on this PR that will be done in separate PRs:

Gracefully persisting a circuit, including sending the state to the client.
Persisting a circuit to distributed storage, which will use HybridCache as a base implementation.

The detailed design can be found #60494

The main changes from the original design as well as some additional details are:

We rely on HybridCache for handling storage to distributed storage mechanisms.
- This means we don't have to create individual packages for different distributed backends (redis, blob).
We provide a default implementation that leverages MemoryCache (same as disconnected circuits in CircuitRegistry) and that stores a limited number of persisted circuits but for a longer period of time (2h is the default).
- We expect the amount of memory used to persist the circuit state to be in the range of dozens to hundreds of KB.
  - The way we persist state on disconnection is equivalent to the way we do so during prerendering and persisting more than 100Kb starts to degrade the experience. (You wouldn't push 10MB of state to a client on the first request).
- Keeping state around for longer is cheaper than keeping the circuit for several reasons:
  - The circuit might continue to do work even if disconnected and consume resources like CPU and memory. The persisted state only consumes a fixed amount of memory that the developer is in control of.
  - The persisted state represents a subset of all the memory consumed by the application (we don't have to keep track of the individual components and so on).
- We retain the persisted circuit state for 2h by default in memory or until we run out of capacity. The default is chosen as a trade-off between the average session duration and the % of circuits that we fail to resume because we discarded the state.
  - Apps need to adjust this to their individual needs based on their user's usage.

MackinnonBuck

Looks great so far - still need to do a deeper review of some parts.

MackinnonBuck · 2025-06-07T20:03:05Z

src/Components/Server/src/Circuits/CircuitPersistenceManager.cs

+        var renderer = circuit.Renderer;
+        var persistenceManager = circuit.Services.GetRequiredService<ComponentStatePersistenceManager>();
+        using var subscription = persistenceManager.State.RegisterOnPersisting(
+            () => PersistRootComponents(renderer, persistenceManager.State),
+            RenderMode.InteractiveServer);
+        var store = new CircuitPersistenceManagerStore();
+        await persistenceManager.PersistStateAsync(store, renderer);
+
+        await circuitPersistenceProvider.PersistCircuitAsync(
+            circuit.CircuitId,
+            store.PersistedCircuitState,
+            cancellation);


If I'm understanding this correctly:

We register a new callback to persist root component state

We then immediately call PersistStateAsync(), which invokes the callback

The callback serializes root components into markers (similar to how prerendering works, which makes sense), which then gets serialized into a JSON byte[] and stored in the Dictionary<string, byte[]> managed by the PersistentComponentState

A custom IPersistentComponentStateStore then receives the aforementioned dictionary in its PersistStateAsync() method, at which point it extracts the root component state from the dictionary and constructs a new Dictionary<string, byte[]> without the root component state

Is this doing more work than necessary? Would it be possible to serialize root component state directly into a JSON byte[] without inserting it into the PersistentComponentState's dictionary only to extract it out shortly thereafter? Then we could just directly assign the root component byte[] to PersistedCircuitState.RootComponents, and directly assign the PersistentComponentState dictionary to PersistedCircuitState.ApplicationState without having to reconstruct it first.

I see that a comment later in this file mentions that the purpose of the callback is to have it run at the same time as other callbacks. Do we expect that removing the callback and instead performing the root component serialization directly after calling PersistStateAsync() would cause issues? If so, would it work to keep the callback but just not call state.PersistAsJson() and instead store the root component state separately to avoid reconstructing the dictionary? Totally possible that I'm missing a detail that makes this impractical!

MackinnonBuck · 2025-06-07T20:04:18Z

src/Components/Server/src/Circuits/CircuitPersistenceManager.cs

+            var localRetention = circuitOptions.Value.PersistedCircuitInMemoryRetentionPeriod;
+            var maxRetention = distributedRetention > localRetention ? distributedRetention : localRetention;
+
+            var marker = ComponentMarker.Create(ComponentMarker.ServerMarkerType, false, componentKey);


Nit:

Suggested change

var marker = ComponentMarker.Create(ComponentMarker.ServerMarkerType, false, componentKey);

var marker = ComponentMarker.Create(ComponentMarker.ServerMarkerType, prerender: false, componentKey);

MackinnonBuck · 2025-06-07T20:05:01Z

src/Components/Server/src/Circuits/DefaultPersistedCircuitCache.cs

+    private readonly Lock _lock = new();
+    private readonly CircuitOptions _options;
+    private readonly MemoryCache _persistedCircuits;
+    private readonly Task<PersistedCircuitState> _noMatch = Task.FromResult<PersistedCircuitState>(null);


Nit: _noMatch could be static.

MackinnonBuck · 2025-06-07T20:06:01Z

src/Components/Server/src/Circuits/DefaultPersistedCircuitCache.cs

+
+        public CancellationTokenSource TokenSource { get; set; }
+
+        public CircuitId CircuitId { get; set; }


I don't see this CircuitId property being set anywhere. Maybe that's missing from PersistCore()?

MackinnonBuck · 2025-06-07T20:06:22Z

src/Components/Server/src/Circuits/IServerComponentDeserializer.cs

-    bool TryDeserializeRootComponentOperations(string serializedComponentOperations, [NotNullWhen(true)] out RootComponentOperationBatch? operationBatch);
+    bool TryDeserializeRootComponentOperations(string serializedComponentOperations, [NotNullWhen(true)] out RootComponentOperationBatch? operationBatch, bool deserializeDescriptors = true);
+
+    public bool TryDeserializeWebRootComponentDescriptor(ComponentMarker record, [NotNullWhen(true)] out WebRootComponentDescriptor? result);


The public modifier isn't necessary

MackinnonBuck · 2025-06-07T20:08:04Z

src/Components/Server/src/ComponentHub.cs

+        }
+
+        PersistedCircuitState? persistedCircuitState;
+        if (rootComponents == "[]" && string.IsNullOrEmpty(applicationState))


Should this line also be using RootComponentIsEmpty() like the else if block below it?

MackinnonBuck · 2025-06-07T20:08:41Z

src/Components/Server/src/Circuits/DefaultPersistedCircuitCache.cs

+namespace Microsoft.AspNetCore.Components.Server.Circuits;
+
+// Default implmentation of ICircuitPersistenceProvider that uses an in-memory cache
+internal sealed partial class DefaultInMemoryCircuitPersistenceProvider : ICircuitPersistenceProvider


Should this file name be changed to match the name of this class?

github-actions bot added the area-blazor Includes: Blazor, Razor Components label Jun 5, 2025

javiercn requested review from SteveSandersonMS and MackinnonBuck June 5, 2025 17:13

This was referenced Jun 5, 2025

System.TimeoutException : The operation has timed out. dotnet/dnceng#5279

Closed

The active test run was aborted. Reason: Test host process crashed dotnet/dnceng#451

Open

javiercn marked this pull request as ready for review June 6, 2025 09:35

javiercn requested a review from a team as a code owner June 6, 2025 09:35

javiercn added 19 commits June 6, 2025 12:48

Circuit persistence implementation

3ba6f76

Added sample

df72b18

Fix DI issues

a147686

Temporarily add JS bits

eccab87

Fixes

24b5ae3

Refine ts

8d95b25

Wire up the default handler

3825a5e

Sample cleanups

ccf570d

Provide expiration timeout for the serialized descriptors

7ef61ea

tmp

011fba4

Add tests

46d4aa5

More tests

1837a4e

More tests

ad9f077

MemoryPersistenceProvider tests

8541277

Add E2E test

1bd578a

Cleanup E2E test

fbd0c10

Undo sample changes

da31a8d

Fix build

cf443bf

Tmp

70da07d

javiercn force-pushed the javiercn/persistent-component-state-ungraceful branch from 7116e55 to 70da07d Compare June 6, 2025 15:38

MackinnonBuck reviewed Jun 7, 2025

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

[Blazor] Adds support for persisting and restoring disconnected circuits from storage #62259

[Blazor] Adds support for persisting and restoring disconnected circuits from storage #62259

javiercn commented Jun 5, 2025 •

edited

Loading

Uh oh!

MackinnonBuck left a comment

Uh oh!

MackinnonBuck Jun 7, 2025

Uh oh!

MackinnonBuck Jun 7, 2025

Uh oh!

MackinnonBuck Jun 7, 2025

Uh oh!

MackinnonBuck Jun 7, 2025

Uh oh!

MackinnonBuck Jun 7, 2025

Uh oh!

MackinnonBuck Jun 7, 2025

Uh oh!

MackinnonBuck Jun 7, 2025

Uh oh!

Uh oh!

	var marker = ComponentMarker.Create(ComponentMarker.ServerMarkerType, false, componentKey);
	var marker = ComponentMarker.Create(ComponentMarker.ServerMarkerType, prerender: false, componentKey);


		public CancellationTokenSource TokenSource { get; set; }

		public CircuitId CircuitId { get; set; }

[Blazor] Adds support for persisting and restoring disconnected circuits from storage #62259

Are you sure you want to change the base?

[Blazor] Adds support for persisting and restoring disconnected circuits from storage #62259

Conversation

javiercn commented Jun 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

MackinnonBuck left a comment

Choose a reason for hiding this comment

Uh oh!

MackinnonBuck Jun 7, 2025

Choose a reason for hiding this comment

Uh oh!

MackinnonBuck Jun 7, 2025

Choose a reason for hiding this comment

Uh oh!

MackinnonBuck Jun 7, 2025

Choose a reason for hiding this comment

Uh oh!

MackinnonBuck Jun 7, 2025

Choose a reason for hiding this comment

Uh oh!

MackinnonBuck Jun 7, 2025

Choose a reason for hiding this comment

Uh oh!

MackinnonBuck Jun 7, 2025

Choose a reason for hiding this comment

Uh oh!

MackinnonBuck Jun 7, 2025

Choose a reason for hiding this comment

Uh oh!

Uh oh!

javiercn commented Jun 5, 2025 •

edited

Loading