[Blazor] Adds support for pausing and resuming circuits with support for pushing the state to the client #62271

javiercn · 2025-06-06T15:40:23Z

Adds support for triggering pauses from the circuit proactively from JavaScript

src/Components/Samples/BlazorUnitedApp/App.razor

src/Components/Server/src/Circuits/Circuit.cs

MackinnonBuck · 2025-06-09T16:20:01Z

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

+        if (saveStateToClient)
+        {
+            await SaveStateToClient(circuit, store.PersistedCircuitState, cancellation);
+        }
+        else
+        {
+            await circuitPersistenceProvider.PersistCircuitAsync(
+                circuit.CircuitId,
+                store.PersistedCircuitState,
+                cancellation);
+        }


From reading this section of code, it wasn't obvious to me that SaveStateToClient actually saves state on the server as a fallback. Do you think it would be clearer if SaveStateToClient was actually TrySaveStateToClient, and the fallback logic is just what's currently in the else block here? Something like:

if (saveStateToClient && await TrySaveStateToClient(...)) { // State successfully saved to the client - nothing left to do on the server } else { await circuitPersistenceProvider.PersistCircuitAsync(...); }

MackinnonBuck · 2025-06-09T16:21:08Z

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

+        // Root components descriptors are already protected and serialized as JSON, we just convert the bytes to a string.
+        var rootComponents = Encoding.UTF8.GetString(state.RootComponents);


Could we avoid encoding/decoding root component state by serializing it directly to a string rather than to a byte[] first via PersistedComponentState.PersistAsJson()?

PersistedComponentState.PersistAsJson()

This will serialize it into a byte array in any case.

I don't think it's super important given that this won't be a super common thing and that we already serialize/stringify 2 or 3 times more than necessary.

I feel that it's better to not do this right now and wait for a time to optimize serialization paths all the way through as a separate piece of work (post 10)

I feel that it's better to not do this right now and wait for a time to optimize serialization paths all the way through as a separate piece of work (post 10)

Sounds good to me 🙂

I've filed #62312 to cover going through this stuff across the board

src/Components/Web.JS/src/Platform/Circuits/CircuitManager.ts

MackinnonBuck · 2025-06-09T16:22:49Z

src/Components/Web.JS/src/Platform/Circuits/CircuitManager.ts

  public async resume(): Promise<boolean> {
    if (!this._circuitId) {
-      throw new Error('Method not implemented.');
+      throw new Error('Circuit host not initialized.');
+    }
+
+    if (this._pausingPromise) {
+      await this._pausingPromise;


Does resume() need to set this._paused back to false?

I've changed how all this stuff works because it was incredibly confusing. I've created a class to encapsulate all these state transitions and simplify things.

There are also now more thorough tests that validate that we can disconnect/reconnect gracefully/ungracefully multiple times and with different combinations

MackinnonBuck · 2025-06-09T16:24:24Z

src/Components/Web.JS/src/Platform/Circuits/DefaultReconnectionHandler.ts

+        isClientPause,
+        remotePause,


I initially thought the isClientPause and remotePause arguments would always have opposite values because I interpreted them as "client-initiated" vs. "server-initiated", but it's actually "are we gracefully pausing" and "if so, who initiated the pause", right? Maybe names like isGracefulPause and isRemoteInitiator might be clearer?

Yes.

I actually changed this as I was working on other stuff.

MackinnonBuck · 2025-06-09T16:27:56Z

src/Components/Web.JS/src/Platform/Circuits/CircuitManager.ts

+    connection.on('JS.SavePersistedState', (circuitId: string, components: string, applicationState: string) => {
+      if (!this._circuitId) {
+        throw new Error('Circuit host not initialized.');
+      }
+      if (circuitId !== this._circuitId) {
+        throw new Error(`Received persisted state for circuit ID '${circuitId}', but the current circuit ID is '${this._circuitId}'.`);
+      }
+      this._persistedCircuitState = { components, applicationState };
+      return true;
+    });


It looks like _persistedCircuitState is just stored in-memory. I've sometimes seen the Edge browser automatically refresh sleeping tabs, which would cause this state to be lost. Should we consider storing persisted state in e.g., local storage so that we handle cases like this?

Definitely not local storage, maybe session storage.

If the browser refreshes the entire page, aren't we getting a new DOM anyways? I'm working under the premise that the document remains intact. If a full-page refresh happens then you lose all state (same as it would happen with any other regular web app or SPA for that matter).

If the page gets unloaded from memory, it's not a scenario that we are trying to tackle (at least for now)

Also, for reference.

In Microsoft Edge, a sleeping tab is discarded when it has been inactive for 1.5 days and the AutoDiscardSleepingTabsEnabled policy is enabled. This helps free up memory by completely unloading the tab from the system. When you switch back to a discarded tab, it will need to reload instead of instantly resuming like a regular sleeping tab.

So, I don't think this is an important scenario for the feature.

If the browser refreshes the entire page, aren't we getting a new DOM anyways? I'm working under the premise that the document remains intact.

Yeah, it would be a new DOM, so you wouldn't retain any state that wasn't represented on the server. I was just thinking it could be helpful to persist server-side state even if DOM state was lost, especially when it can be used to re-hydrate the DOM (e.g., two-way bindings). But I think it's fine to consider this out of scope.

In Microsoft Edge, a sleeping tab is discarded when it has been inactive for 1.5 days and the AutoDiscardSleepingTabsEnabled policy is enabled...
So, I don't think this is an important scenario for the feature.

Just to clarify, is it not important because we don't expect customers to resume a session that's 1.5 days old?

Yeah, it would be a new DOM, so you wouldn't retain any state that wasn't represented on the server. I was just thinking it could be helpful to persist server-side state even if DOM state was lost, especially when it can be used to re-hydrate the DOM (e.g., two-way bindings). But I think it's fine to consider this out of scope.

This feature persists the state for the session. If the browser triggers a full reload of the page is a new session altogether.

If we get feedback about it, I'd be open to reconsider after 10, but I do consider that out of scope for 10. To put it in different terms, this feature works within constraints similar to those of re-connect, it's just "an enhanced version".

It's not meant to do things like preserving state when you press F5 or things like that as how GH and other apps do it. That would be IMO a separate thing that we would build (in that case, rightfully, against sessionStorage).

pavelsavara

just questions, no need to answer them in today ...

pavelsavara · 2025-06-11T11:43:29Z

src/Components/Server/src/ComponentHub.cs

+    //   * If that succeeds, the client receives the state and we are done.
+    //   * If that fails, we will fall back to the server-side cache storage.
+    // * The client will disconnect after receiving the state or after a 30s timeout.
+    //   * From that point on, it can choose to resume the circuit by calling ResumeCircuit with or without the state


What happens if client calls the resume() in the middle of pending pause->push to client workflow?

We push to the client when the client initiates the pause explicitly, so at that point the client must have called pause() which resume() is aware of and will await until pause() completes before trying the resume() operation.

pavelsavara · 2025-06-11T11:46:36Z

src/Components/Web.JS/src/Boot.Server.Common.ts

@@ -67,6 +67,20 @@ async function startServerCore(components: RootComponentManager<ServerComponentD
    return true;
  };

+  Blazor.pause = async () => {


C# is PauseCircuit, should it match ? Same for JS resume()

The methods in the SignalR hub are a private implementation detail, we didn't make them match in the past (for example we have reconnect and ConnectCircuit.

That said, I think it's worth changing the names for pause and resume to something more concrete. Since this will have to go through API review, I will hold on renaming it for now, but I'll cover it as part of the API review.

pavelsavara · 2025-06-11T11:52:21Z

src/Components/Web.JS/src/Platform/Circuits/CircuitManager.ts

+
+      // Notify the reconnection handler that we are pausing the circuit.
+      // This is used to trigger the UI display.
+      this._options.reconnectionHandler?.onConnectionDown(this._options.reconnectionOptions, undefined, true, remote);


is this behavior "breaking change" ?

No, in the sense that is a new feature.

If you have a custom reconnectionHandler and you call pause() in your code is up to you to make sure that your handler is capable of handling it.

The default handler (which is by far the most common case) will handle this automatically, same as the built-in UI. If you had a custom UI on previous versions it will behave as the reconnect UI

pavelsavara · 2025-06-11T11:54:51Z

src/Components/Web.JS/src/Platform/Circuits/CircuitManager.ts

+    if (this._resumingState.isInprogress()) {
+      // If we are already resuming, wait for the current resume operation to complete.
+      this._logger.log(LogLevel.Trace, 'Waiting for the circuit to finish resuming...');
+      return this._resumingState.currentProgress();


could resuming fail at this point ? We return from the method and reconnect code below would not run.

The only one that sets up the resuming promise is this method. The way this works is that the first time you call it, we set the state, the second time you call it, you get the promise created in the first call. (for example if you call resume(); resume(); you get the same promise back both times)

pavelsavara · 2025-06-11T11:55:44Z

src/Components/Web.JS/src/Platform/Circuits/CircuitManager.ts

+  }
+
+  public transitionTo(newState: T): void {
+    if (this._promise) {


are there any invalid transitions on the graph ?

Nope.

This helper class roughly encapsulates the transitions to make thins "saner" when we set them up in the CircuitManager. The CircuitManager takes care of transitioning the right way.

javiercn marked this pull request as ready for review June 6, 2025 19:20

javiercn requested a review from a team as a code owner June 6, 2025 19:20

javiercn requested review from SteveSandersonMS and MackinnonBuck June 6, 2025 19:21

javiercn commented Jun 6, 2025

View reviewed changes

src/Components/Samples/BlazorUnitedApp/App.razor Outdated Show resolved Hide resolved

build-analysis bot mentioned this pull request Jun 6, 2025

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

Closed

3 tasks

javiercn force-pushed the javiercn/persistent-component-state-graceful branch from dcfe665 to 4ae47fd Compare June 8, 2025 22:12

MackinnonBuck reviewed Jun 9, 2025

View reviewed changes

javiercn force-pushed the javiercn/persistent-component-state-ungraceful branch 2 times, most recently from cf5a455 to aea83a7 Compare June 10, 2025 09:57

javiercn force-pushed the javiercn/persistent-component-state-graceful branch from 4ae47fd to 816f93b Compare June 10, 2025 10:59

javiercn requested a review from a team June 10, 2025 15:13

MackinnonBuck approved these changes Jun 10, 2025

View reviewed changes

javiercn requested review from ilonatommy, maraf and pavelsavara June 11, 2025 10:54

pavelsavara approved these changes Jun 11, 2025

View reviewed changes

javiercn force-pushed the javiercn/persistent-component-state-ungraceful branch from aea83a7 to 8582da8 Compare June 11, 2025 13:46

javiercn requested review from BrennanConroy and halter73 as code owners June 11, 2025 13:46

javiercn closed this Jun 11, 2025

javiercn force-pushed the javiercn/persistent-component-state-graceful branch from f17b908 to 8582da8 Compare June 11, 2025 13:48

javiercn reopened this Jun 11, 2025

Base automatically changed from javiercn/persistent-component-state-ungraceful to main June 11, 2025 17:53

build-analysis bot mentioned this pull request Jun 11, 2025

RestApiException`1: The response contained an invalid status code 500 Internal Server Error dotnet/dnceng#2298

Open

3 tasks

javiercn added 5 commits June 11, 2025 21:22

Add support for manually pausing and resuming circuits

8f3d70b

Support remote pausing circuits from the server

658753f

UI support

dfeea17

Fixes

913957e

Fix build

eeaa848

javiercn added 13 commits June 11, 2025 21:22

Unit tests

4a5034d

E2E tests

4499ec6

Fix build

c240d64

Cleanup

dd7959d

Fixes

ffcc8e1

More tests

6eb17b1

Fix test

63e12e3

Add tests for custom UI and update templates

f184179

Custom UI tests

b3fd9df

Revert sample changes

bbee217

Remove additional changes

c1aa891

Remove empty file

ef52ce9

Remove remote pause code

b6632dd

javiercn force-pushed the javiercn/persistent-component-state-graceful branch from e5a076c to b6632dd Compare June 11, 2025 19:22

javiercn enabled auto-merge (squash) June 11, 2025 19:32

javiercn merged commit 16438b6 into main Jun 12, 2025
27 checks passed

javiercn deleted the javiercn/persistent-component-state-graceful branch June 12, 2025 00:21

dotnet-policy-service bot added this to the 10.0-preview6 milestone Jun 12, 2025

This was referenced Jun 12, 2025

APIs for components to persist state across circuits manually #30344

Closed

Blazor Server: Provide APIs/extensibility for circuit eviction #17866

Closed

		// Root components descriptors are already protected and serialized as JSON, we just convert the bytes to a string.
		var rootComponents = Encoding.UTF8.GetString(state.RootComponents);

[Blazor] Adds support for pausing and resuming circuits with support for pushing the state to the client #62271

[Blazor] Adds support for pausing and resuming circuits with support for pushing the state to the client #62271

Uh oh!

Conversation

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

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

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

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

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

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

pavelsavara left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

javiercn commented Jun 6, 2025 •

edited

Loading

javiercn Jun 10, 2025 •

edited

Loading

MackinnonBuck Jun 10, 2025 •

edited

Loading