Server-side Blazor Scoped injection is very unhelpful

[masonwheeler]

Summary

Scoped injection of services should operate per-session rather than per "request."

Motivation and goals

In a classic website, it makes sense to have scoped DI inject a new service per HTTP request. HTTP is a stateless protocol, so the implementation matches the reality of the way it's used.

This is not the case in Blazor. A single-page application is not conceptually a web request; it's conceptually an application that happens to be running in a browser, and applications are not stateless. When using server-side rendering, scoped DI injects new instances of services you've used previously at unexpected times, resulting in errors because your application state does not stay where you left it.

This occurs because scoped DI is still scoped per-request, which may be correct on a very pedantic technical level, but is entirely unhelpful since this isn't the use case it was designed for. For Blazor, there needs to be a way to inject services per-session, that will remain around for the entire usage of the SPA, either by modifying the scoped DI implementation or by adding a new option.

In scope

If Blazor code injects a scoped service, the entire SPA should see that same object instance forever, until the user leaves/reloads the SPA or the server shuts down, no matter how many different "requests" and navigation events occur along the way.

Out of scope

No effort needs to be made to make this application state persist between multiple sessions by the same user. A reload is still a reload.

Risks / unknowns

If existing code depends on the current behavior in some way, it could cause unexpected consequences. So adding an explicit session-scoped option might be the better course of action.

Examples

This all arose out of a Discord discussion of a crash bug in my project. I have a service that's loading some data from the database. It's being called in the layout, and if I'm opening a page that also wants data from the database, I get:

InvalidOperationException: A second operation was started on this context instance before a previous operation completed. This is usually caused by different threads concurrently using the same instance of DbContext.

And due to the design of Blazor, throwing this exception brings down the entire SPA.

This occurs no matter what efforts are made to get this data only once and persist it in memory, because the memory in question keeps getting replaced out from under me. This needs to stop happening. I'm building an application, and application state needs to stay where the developer left it.

Some people in chat suggested various solutions involving caching user data per-user, but this is not a persuasive suggestion.

• Users can leave, and then you have stale data bloating up the cache.
  • Setting up timed cache eviction policies can bring you right back to where you started, with application state vanishing out from under you, if the user steps away from the SPA for a few minutes. There's a reason this is called one of the Hard Problems Of Computer Science.
• Even if invalidation wasn't an issue, now every service that deals with application state becomes significantly more complex as it has to interact with the cache for everything, rather than just keeping it inside its own object.

What is needed is proper scoping that actually works with the SPA model.

[garrettlondon1]

Blazor SSR will use a different DI scope than the circuit, there is no way around that

Blazor SSR behaves the exact same as Web API, where scoped services are available for the lifetime of the request

Blazor InteractiveServer, Scoped Services are available for the lifetime of the websocket connection (either on disconnect or hard refresh)

If you want to hold state beyond navigation, put it in a scoped service on the circuit

If you want to statically render html like a Web API, then yes scoped services will be disposed at the end of the request

That is the benefit of Blazor Web, to have interactive islands and not the whole app.. if you want the whole app to hold state, use InteractiveServer globally and use scoped services to persist state for the whole socket. You can even store that state in Redis or something and use a custom CircuitHandler to initialize the state if a user opens a new Circuit

Let me know if I misread anything

[masonwheeler]

@garrettlondon1 You said "circuit" several times in here. What's a circuit, and how are things scoped to that rather than to HTTP requests? Because what I'm seeing is some things scoped to a websocket connection and others to an HTTP connection, and application state that may or may not disappear out from under me when I change from one page to another.

What I want is an application that behaves like an application, where the state stays where I left it throughout the life of the application. Can circuits help me accomplish that?

You can even store that state in Redis or something

See above, re: caches are a bad solution here.

[garrettlondon1]

@masonwheeler ,

You are correct my friend, a Circuit is a SignalR concept

Blazor Server (InteractiveServer) is built on top of a persistent SignalR connection

Each user session and all component state is stored in a "Circuit"

For a Web API and for Blazor SSR, scoped services live for the request lifetime

For Blazor Server, scoped services live in the circuit until the circuit is disposed and the client opens a new circuit, which is what blazor.web.js does if you use InteractiveServer

How does a Circuit get disposed? Not through enhanced navigation, it only gets disposed when the client disconnects, or Blazor determines you no longer have a need for the circuit anymore..

You can easily prevent this by putting an InteractiveServer component in the NavBar, then, every page switch you will need to use a websocket to power that component..

The circuit is long lived, but its not really stable or reliable in the sense that you would use it for hours..

Maybe Blazor WASM with a singleton service can accomplish what you want?

There are other places like session storage, localstorage, redis, to store state

Why don't you like the stateless nature of calling the db to get state? That is what the industry has moved towards it seems. Blazor Server Scoped Services are really meant to be for UI state, you're not going to persist business data across components that don't need it. Transient services or viewmodels or code behind should be used to display information.. can you expand on how you want it to behave like an "application"?

[garrettlondon1]

Sorry, just read the intro about stateless apps..

Regarding your Dbcontext issue, it is because you are not using DbContextFactory..

In Blazor Server, every individual db operation needs to have a new dbcontext created using a dbcontextfactory approach

You cannot use DI with DbContext in Blazor Server safely

[masonwheeler]

@garrettlondon1

can you expand on how you want it to behave like an "application"?

In a desktop application, if you have a piece of state anywhere in the program, it stays where you put it. If you set a value on some object somewhere, and then come back to it 5 hours later, the value will still be what you set 5 hours ago.

You cannot use DI with DbContext in Blazor Server safely

Then why did the Microsoft-provided Blazor template set it up that way? 😖

[garrettlondon1]

Why not use protected session store or local storage? Same concept on the client in the browser

https://github.com/Blazored/SessionStorage

Circuit is not the right fit for that kind of persistent app state

[garrettlondon1]

As far as I know no blazor template uses the dbcontext at all

[masonwheeler]

As far as I know no blazor template uses the dbcontext at all

"Blazor Web App" with the "Individual Accounts" authentication option. It uses EF to manage user accounts.

[garrettlondon1]

Yeah but those Identity pages are static, which means DbContext injection is safe.. its only once you add interactive server to it, that you need to use a factory

[masonwheeler]

And yet, pulling up one of those pages was what caused the InvalidOperationException mentioned above.

[javiercn]

You are correct my friend, a Circuit is a SignalR concept

Circuits are not a signalr concept. Circuits are a blazor concept. A circuit refers to an interactive Blazor Server session

[javiercn]

@masonwheeler thanks for contacting us.

As @garrettlondon1 points out, this is not a question of DI scopes or anything similar. It essentially has to do with the concurrent nature of Blazor rendering and the fact that EF doesn't support concurrent queries.

This is easy for you to test if you want. Grab a Db context, issue two queries and just capture the task for the first one without awaiting it. You'll see that error in a console app.

With regards to the state,

The state for a Blazor server app will be alive for as long as your circuit is alive. If you are using global interactivity (meaning the routing happens client-side instead of through enhanced navigation) your circuit will be alive from the time the app starts to when the user closes the tab.

That said, what @garrettlondon1 mentions about there being two scopes is correct. There's one scope where everything is prerendered, an HTML response is generated and the state is discarded, and then there's the interactive scope which happens when the app starts in interactive mode and that lasts for the remaining of the app lifetime.

If you want to transfer state from the first scope to the second, you can use PersistentComponentState to do so.

Now, with regards to your comment,

In a desktop application, if you have a piece of state anywhere in the program, it stays where you put it. If you set a value on some object somewhere, and then come back to it 5 hours later, the value will still be what you set 5 hours ago.

This is fine if you do it on a client app because you are using the machine resources. In a blazor server app those resources are shared with other users, so you don't want to keep anything around that you don't need.

Again, to summarize:

• The problem you are facing is not related to scopes, but to limitations on EF. Use DbContextFactory as our docs suggest, you can wrap that into a scoped service and the data will remain there for the entire lifetime of that render mode.
• If you want to pass data from prerendering to an interactive mode, you need to use persistent component state to do so.