@lewing could you do a once-over to make sure this is the right change?

• What changed that broke this?
• Also, @pranavkm are there are "functional" tests, where the app is run? It would be useful to have a test like that for this case

are there are "functional" tests, where the app is run? It would be useful to have a test like that for this case

+1

What changed that broke this?

I'm pretty sure my change to fix dotnet/runtime#49391 exposed this bug in how environment variables are handled in WASM. I think this was always broken, but because the error was being eaten, no one noticed.

There is also dotnet/runtime#56667

There are E2E wasm tests, like https://github.com/dotnet/aspnetcore/blob/main/src/Components/test/E2ETest/Tests/WebAssemblyGlobalizationTest.cs . One for this case can be added there.

What changed that broke this?

I'm pretty sure my change to fix dotnet/runtime#49391 exposed this bug in how environment variables are handled in WASM. I think this was always broken, but because the error was being eaten, no one noticed.

This is about the timing of the call that sets up the environment. Blazor has its own startup code and does a lot in preRun which is too early for some things (it actually triggers emscripten assertions if you enable them).

There are E2E wasm tests, like https://github.com/dotnet/aspnetcore/blob/main/src/Components/test/E2ETest/Tests/WebAssemblyGlobalizationTest.cs . One for this case can be added there.

Is there a test that is already covering this, but was disabled?

Hi @radical. It looks like you just commented on a closed PR. The team will most probably miss it. If you'd like to bring something important up to their attention, consider filing a new issue and add enough details to build context.