Auto mode can lead to running Server and WebAssembly in the page at the same time

[SteveSandersonMS]

Scenario:

• Page starts and activates some Auto components. They resolve as Server.
• In the background, wasm assets get downloaded
• User does enhanced nav to another page. Some components are retained, and some new Auto ones are added.
• The new Auto ones resolve as WebAssembly and start up on that runtime, and the retained Server components continue running on Server. So now both modes are in use in the page at the same time.

This could be a potential source of hard-to-repro and hard-to-fix bugs. For example, if the app uses an AppState-like pattern, where some DI service is used to broker messages/events across components, then now all the Server components will talk to each other, and all the WebAssembly components will talk to each other, but no messages/events will span the two silos. This is particularly confusing because the app will work fine if the user refreshes the page, or if their network is so slow it never downloads WebAssembly.

Possibly an even more concrete scenario:

• HeadOutlet is Auto and resolves as Server
• Some pages are Auto and initially resolve as Server but later resolve as WebAssembly, at which point the page title stops updating (at least, it can no longer update dynamically between navigations, e.g., when incrementing a counter)

Possible resolution

For as long as there's at least one live Server root component in the page, we could continue to resolve Auto as Server.

[MackinnonBuck]

Maybe something like this would work:

For any newly-added component with an auto render mode...

• If WebAssembly components exist on the page, use WebAssembly
• Otherwise, if Server components exist on the page, use Server
• Otherwise, if WebAssembly resources are cached, use WebAssembly
• Otherwise, use Server

[SteveSandersonMS]

Given that:

• we never have wasm components until the wasm resources are cached
• once the wasm resources are cached, they don't stop being cached

... is the first bullet point in your list redundant?

[MackinnonBuck]

... is the first bullet point in your list redundant?

Let's say you had an Auto component on the page that previously resolved to a Server render mode, and then another component with an explicitly WebAssembly render mode. The circuit might be active, but you would probably want to resolve future Auto components to mean WebAssembly so that we can close the circuit if the existing Server component gets removed.

However, it's going to be really hard to know whether the new Auto component will need to share state with either the Server component or the WebAssembly component in that case. In your HeadOutlet example, we'd actually want to resolve the new Auto component to use Blazor Server.

[SteveSandersonMS]

I see, thanks. Yes, I didn't think of cases where the developer intentionally causes mismatches. As you say, there's no way to know what best matches the developer's intent in that situation.

I think that in cases where we can keep all the components on the same hosting platform, that's desirable, and avoids a wide range of difficult edge-cases. But in cases where the developer explicitly forces a mixed mode, I'm more OK with whatever behavior since there's no definite best choice.

So yes, I think your analysis and your four bullet points all seem correct and necessary!

[MackinnonBuck]

Completed in #50851