Unintentional change to Blazor WebAssembly startup promise semantics

[SteveSandersonMS]

Follow-up from #31769 (review)

It looks like an unintended consequence of #31769 was changing the behavior of the promise we return from Blazor.start:

• On Blazor Server, Blazor.start returns a promise that resolves when the .NET code starts up and the app becomes interactive
• On WebAssembly:
  • Prior to this PR, Blazor.start behaves the same as server (the promise resolves when the app becomes interactive)
  • Since this PR, Blazor.start returns a promise that doesn’t resolve until the .NET app exits, which typically means never, and hence prevents its usage for triggering post-.NET startup logic

The fault here is not in the PR, but is with us not previously having added any E2E coverage for this behavior on WebAssembly (though we do have coverage for it on Server).

Ideally we should fix this before preview 4 ships.

Possible fix

The absolute simplest thing to do would be just removing the await keyword from the line where we call platform.callEntryPoint. Going further, it would be great to also add an E2E test for this behavior on WebAssembly.

[SteveSandersonMS]

cc @TanayParikh @mkArtakMSFT

[javiercn]

@SteveSandersonMS that sounds good to me

[captainsafia]

Thanks for this write-up. Can you point me to the test scenario we use to validate this in server?

Since this PR, Blazor.start returns a promise that doesn’t resolve until the .NET app exits, which typically means never, and hence prevents its usage for triggering post-.NET startup logic

So something like this would no longer work in WASM?

Blazor.start().then(() => {
  // some initialization logic
});

[SteveSandersonMS]

Thanks for this write-up. Can you point me to the test scenario we use to validate this in server?

Sure. This line of code is where we tell the Blazor Server tests they are OK to start executing, so if it never ran, the tests would wait forever. There isn't any equivalent to that in our WebAssembly tests AFAIK.

So something like this would no longer work in WASM?

Yes, exactly.

[TanayParikh]

Thanks @SteveSandersonMS for pointing this out! Put up a PR here: #31978