-
Notifications
You must be signed in to change notification settings - Fork 10.4k
Remove await for WASM platform.callEntryPoint
#31978
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove await for WASM platform.callEntryPoint
#31978
Conversation
Hello human! Please make sure you've included the Shiproom Template in a comment or (preferably) the PR description. Also, make sure this PR is not marked as a draft and is ready-to-merge. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changes look fine. As part of merging this in to main, could we add a test for this? I was under the impression that we had end-to-end coverage for all of the startup behavior.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice one!
+1 on the E2E test if possible, though if it ends up being complicated for some reason we could proceed with out it for now.
Did the manual validation by running the |
Hello human! Please make sure you've included the Shiproom Template in a comment or (preferably) the PR description. Also, make sure this PR is not marked as a draft and is ready-to-merge. |
* Remove await for WASM `platform.callEntryPoint` Also added an E2E test. Addresses #31971 Insertion into preview 4: dotnet/aspnetcore#31978 * Update src/Components/test/E2ETest/Tests/StandaloneAppTest.cs
Description
Regression introduced via: #31769
Blazor.start
returns a promise that resolves when the .NET code starts up and the app becomes interactiveBlazor.start
behaves the same as server (the promise resolves when the app becomes interactive)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 logicThis PR is meant to revert that specific bit of logic, so that we no longer await the
platform.callEntryPoint
function and thusBlazor.start
returns a promise that resolves when the .NET code starts up and the app becomes interactive. This now matches the behavior from 6.0-preview3.Customer Impact
Without this PR we inadvertently introduce a breaking change where the
Blazor.start
promise doesn't resolve until the .NET app exits. This prevents its usage for triggering post-.NET startup logic.Regression?
[If yes, specify the version the behavior has regressed from]:
Regression from 6.0-preview3
Regressed by: #31769
Risk
[Justify the selection above]
Returning the
await
logic to what it was prior to #31769 which was introduced in Preview 4.Verification
platform.callEntryPoint
#31997Packaging changes reviewed?
Addresses #31971