PersistentComponentState: large state will crash the client, unable to recover

[Bouke]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

I was debugging an issue with a page that rendered, but started showing the "reconnecting" dialog after ~20 seconds or so. There was no error server-side and the client-side contained rather unhelpful traceback:

[Error] [2022-11-08T09:44:35.259Z] Error: Error: Circuit host not initialized.
log (blazor.server.js:1:115822)
(anonymous function) (blazor.server.js:1:122515)
asyncFunctionResume
(anonymous function)
promiseReactionJobWithoutPromise
promiseReactionJob

After some investigation I've found a similar issue with this message: #44280 (comment). This is a severe problem in our situation, as we don't know beforehand the pre-rendered size of certain data. The failure mode here is completely wrong: when you go over the limit, the client will fail to initialize and you have no way of detecting this nor recovering.

Expected Behavior

State preservation should fail server-side when trying to persist data that will be over the limit.

Steps To Reproduce

@page "/weather-forecast-preserve-state"
@implements IDisposable
@using BlazorSample.Shared
@inject IWeatherForecastService WeatherForecastService
@inject PersistentComponentState ApplicationState

<PageTitle>Weather Forecast</PageTitle>

<h1>Weather forecast</h1>

<p>This component demonstrates fetching data from the server.</p>

@if (forecasts == null)
{
    <p><em>Loading...</em></p>
}
else
{
    <table class="table">
        <thead>
            <tr>
                <th>Date</th>
                <th>Temp. (C)</th>
                <th>Temp. (F)</th>
                <th>Summary</th>
            </tr>
        </thead>
        <tbody>
            @foreach (var forecast in forecasts)
            {
                <tr>
                    <td>@forecast.Date.ToShortDateString()</td>
                    <td>@forecast.TemperatureC</td>
                    <td>@forecast.TemperatureF</td>
                    <td>@forecast.Summary</td>
                </tr>
            }
        </tbody>
    </table>
}

@code {
    private WeatherForecast[] forecasts = Array.Empty<WeatherForecast>();
    private PersistingComponentStateSubscription persistingSubscription;

    protected override async Task OnInitializedAsync()
    {
        persistingSubscription = 
            ApplicationState.RegisterOnPersisting(PersistForecasts);

        if (!ApplicationState.TryTakeFromJson<WeatherForecast[]>(
            "fetchdata", out var restored))
        {
            forecasts = 
                await WeatherForecastService.GetForecastAsync(DateTime.Now);
        }
        else
        {
            forecasts = restored!;
        }
    }

    private Task PersistForecasts()
    {
        ApplicationState.PersistAsJson("fetchdata", Enumerable.Repeat(forecasts.First(), 10_000).ToArray());

        return Task.CompletedTask;
    }

    void IDisposable.Dispose()
    {
        persistingSubscription.Dispose();
    }
}

Exceptions (if any)

No response

.NET Version

6.0.402

Anything else?

No response

[guardrex]

I'm calling this out in the Prerendering and Integration doc and the Persist Component State TH doc with cross-links to our SignalR message size limit coverage, and I'll be 👂 here for anything else we can do on the docs side in a follow-up docs PR.

[javiercn]

@Bouke thanks for contacting us.

You are hitting the SignalR message size limit, which is about 20K. You can either increase that limit (there are security implications to doing so) or reduce the amount of data you are serializing on to the page.

[guardrex]

I thought it was 32K ... is that not right? I need to make a doc change if it's 20K now.

Nevermind ... 32K ...

https://learn.microsoft.com/en-us/aspnet/core/signalr/configuration?view=aspnetcore-6.0&tabs=dotnet#configure-server-options

[javiercn]

@guardrex It's 32K but we put other stuff in there, so it is effectively less. 20K is what we consider to be "safe" by default.

[Bouke]

There are at least the following issues here:

• Bad: Server-side you don't get any feedback/notification/exception that you are over the limit.
• Worse: client gets into a reconnect loop.
• Worser: client logs some generic error in the console.
• Worst: client is unable to recover from this situation.

I don't see how your reply resolves this issue?

[javiercn]

@Bouke the message size is a well-known constraint that is there for security purposes. It is documented as part of https://learn.microsoft.com/en-us/aspnet/core/blazor/security/server/threat-mitigation?view=aspnetcore-7.0#denial-of-service-dos-attacks

Bad: Server-side you don't get any feedback/notification/exception that you are over the limit.

There are logs on the client dev tools as well as on the server (enable debug logging and detailed errors).

Worse: client gets into a reconnect loop.

How so? If the circuit fails to start because a client exceeds the message size the app does nothing else.

Worser: client logs some generic error in the console.

The client knows nothing about what happened, other than the server rejected the message.

Worst: client is unable to recover from this situation.

You have the choice to pick between a higher message size or reduce the amount of data you serialize as part of prerendering. This is an issue in your app as it is not operating within the default constraints.

This issue has been resolved and has not had any activity for 1 day. It will be closed for housekeeping purposes.

See our Issue Management Policies for more information.