[Bug] Session Storage Limit

[JackRFoulkes]

Describe the bug
Attempting to retrieve a list of stored objects from session storage causes the following error:

To Reproduce
Steps to reproduce the behavior:

1. Create two new classes (these have been generated for me from EF Core). Here are the definitions:

    public partial class IISDashboardUserSetting
    {
        public string UserSettingId { get; set; }
        public string UserId { get; set; }
        public string SettingId { get; set; }
        public string Value { get; set; }
        public virtual IISDashboardSetting Setting { get; set; }
    }

    public partial class IISDashboardSetting
    {
        public IISDashboardSetting()
        {
            IISDashboardUserSettings = new HashSet<IISDashboardUserSetting>();
        }

        public string SettingId { get; set; }
        public string Name { get; set; }
        public string Description { get; set; }

        [JsonIgnore]
        public virtual ICollection<IISDashboardUserSetting> IISDashboardUserSettings { get; set; }
    }

2. From the database a populated a list of IISDashboardUserSettings with 113 items:

        public List<IISDashboardUserSetting> GetUserSettingsById(string userId)
        {
            using (var eQuipDBContext = eQuipContextFactory.CreateDbContext())
            {
                var userSettings = eQuipDBContext.IISDashboardUserSettings
                    .Include(s => s.Setting)
                    .Where(u => u.UserId == userId).ToList();

                return userSettings;
            }
        }

3. Store the list in session storage:

            if (modelUserSettings != null || modelUserSettings.Count > 0)
            {
                //We have all the settings...
                await SessionStorageService.SetItemAsync("settings", modelUserSettings);
                StateHasChanged();
            }

4. Attempt to retrieve the stored list:

        public async Task<List<IISDashboardUserSetting>> FetchUserSettingsFromStorage()
        {
            return await SessionStorageService.GetItemAsync<List<IISDashboardUserSetting>>("settings");
        }

Expected behavior
Expect to retrieve the list successfully for use in the application.

Screenshots
See above steps.

Hosting Model (is this issue happening with a certain hosting model?):

• Blazor Server

Additional context
I removed 20 items and tested the same steps and the problem went away.

[chrissainty]

Have you tried doing the same thing with Blazor WebAssembly? Have you tried debugging? How much data are you trying to store?

You need to provide a lot more information when opening an issue. Hence I created the templates.

[JackRFoulkes]

Have you tried doing the same thing with Blazor WebAssembly? Have you tried debugging? How much data are you trying to store?

You need to provide a lot more information when opening an issue. Hence I created the templates.

Thanks for the feedback, I have now updated my original post.

[jamsoftperu]

I had the same problem when I tried to get a string session variable with 79373 characters

Store Session variable

await objSessionStorageService.SetItemAsync(LoginKey.USUARIO_SISTEMA, dataUsuario);

Get Session variable

var data = await objSessionStorageService.GetItemAsStringAsync(LoginKey.USUARIO_SISTEMA);

Error

[chrissainty]

@jamsoftperu @JackRFoulkes Are you both using Blazor Server? Have you tried doing this with Blazor WebAssembly to see if you get the same results?

[jamsoftperu]

@jamsoftperu @JackRFoulkes Are you both using Blazor Server? Have you tried doing this with Blazor WebAssembly to see if you get the same results?

Same results

[jamsoftperu]

I had the solution!! the problem was configuration of SignalR service, add this to configuration to solve the problem:
services.AddSignalR(hubOptions =>
{
hubOptions.MaximumReceiveMessageSize = 10 * 1024 * 1024; // 10MB
});

[Bond-Addict]

I know this was closed in 2021, but its definitely still relevant in 2024 so maybe this will help someone else. I had the exact problem and @jamsoftperu did provide a correct solution.

That being said, I think this would be better and is the route I've taken after researching what that configuration actually does.

if (modelUserSettings != null || modelUserSettings.Count > 0)
{
    //Removes session item so the default signal r storage doesn't run out of space. If no item exists, no action is taken
    await SessionStorageService.SetItemAsync("settings", modelUserSettings);
    //Adds or re-adds the session item to signal r session storage
    await SessionStorageService.SetItemAsync("settings", modelUserSettings);
    StateHasChanged();
}

by doing it this way, you won't worry about running out of storage unless your initial object is larger than the default MaximumReceiveMessageSize which is 32 KB, in which case you will need to do builder.Services.AddSignalR(hubOptions => hubOptions.MaximumReceiveMessageSize = 10 * 1024 * 1024); (Doesn't have to be that big, just as big as your max session item would ever be. You can always adjust it up or down if things change) or else you'll get the same exception but this time on the first call to SessionStorageService.SetItemAsync().

Additional documentation on .Net Core Signal R can be found here.

If I am mistaken and @jamsoftperu has the better approach, please let me know so I can learn too😃

Either way, @jamsoftperu you're the man. I've been beating my head against this issue since I inherited the app and although it's huge pain and made for a bad time all around but everyone just dealt with it and ignored it. Well after having to start and stop my Blazor app to test changes with a report generated using the session storage about 100 times one day because generating the report again cause a total gridlock, I swore I'd never do that again 😆

I can finally put this issue to bed and get back to the rest of the spaghetti code 🤣

P.S. @chrissainty since this still seems to be easy thing mess up in 2024 even (due to the documentation on what they different available methods do behind the scenes), I think it would really better to have SetItemAsync remove the old session item automatically and replace it, if its to basically be a single replacement for both creation and updates of a session item. The same as if var a =1; and then you say a=2; a is then 2.
I think having clearly laid out complete CRUD functionality would mitigate others running in this issue in the future.
It also be good to update the readme with a high-level overview of what each available sync and async methods do.

Whether or not changes are done as made such as additional methods or background logic changes on SetItemAsync, this alone put people that are not familiar with Blazored on an immediate road to success. Also having a section in the readme listing common issues (like this one) with a simple explanations as to why they would happen and also providing the known solutions, would be awesome as well.

[MichiganMan83]

First, thanks a bunch to chrissainty for putting this library together - it's been an integral part of my first Blazor Server app. Great job!

I'm with Bond-Addict here. I would love to see a simple warning in the ReadMe to alert devs to this issue. A lot of us are new to Signal-R and just don't know some of these edges.

Cheers to jamsoftperu for the solution!