Skip to content

Remove await for WASM platform.callEntryPoint #31997

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

Merged
merged 2 commits into from
Apr 21, 2021

Conversation

TanayParikh
Copy link
Contributor

Also added an E2E test.

Addresses #31971

Insertion into preview 4: #31978

Also added an E2E test.

Addresses #31971

Insertion into preview 4: #31978
@TanayParikh TanayParikh requested a review from a team as a code owner April 20, 2021 22:23
@ghost ghost added the area-blazor Includes: Blazor, Razor Components label Apr 20, 2021
mkArtakMSFT pushed a commit that referenced this pull request Apr 21, 2021
## Description

Regression introduced via: #31769

* 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 #31769, `Blazor.start` behaves the same as server (the promise resolves when the app becomes interactive)
  * Since #31769, `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

This PR is meant to revert that specific bit of logic, so that we no longer await the `platform.callEntryPoint` function and thus `Blazor.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?
- [x] Yes
- [ ] No

[If yes, specify the version the behavior has regressed from]: 

Regression from 6.0-preview3 
Regressed by: #31769

## Risk
- [ ] High
- [ ] Medium
- [x] Low

[Justify the selection above]
Returning the `await` logic to what it was prior to #31769 which was introduced in Preview 4.

## Verification
- [x] Manual (required)
- [x] Automated: #31997

## Packaging changes reviewed?
- [ ] Yes
- [ ] No
- [x] N/A

Addresses #31971
@TanayParikh TanayParikh merged commit 5d8525c into main Apr 21, 2021
@TanayParikh TanayParikh deleted the taparik/removeAwaitOnWasmCallEntryPoint_INTO_MAIN branch April 21, 2021 17:41
@ghost ghost added this to the 6.0-preview5 milestone Apr 21, 2021
3dots pushed a commit to 3dots/aspnetcore-Web.JS that referenced this pull request Feb 19, 2024
## Description

Regression introduced via: #31769

* 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 #31769, `Blazor.start` behaves the same as server (the promise resolves when the app becomes interactive)
  * Since #31769, `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

This PR is meant to revert that specific bit of logic, so that we no longer await the `platform.callEntryPoint` function and thus `Blazor.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?
- [x] Yes
- [ ] No

[If yes, specify the version the behavior has regressed from]: 

Regression from 6.0-preview3 
Regressed by: #31769

## Risk
- [ ] High
- [ ] Medium
- [x] Low

[Justify the selection above]
Returning the `await` logic to what it was prior to dotnet/aspnetcore#31769 which was introduced in Preview 4.

## Verification
- [x] Manual (required)
- [x] Automated: dotnet/aspnetcore#31997

## Packaging changes reviewed?
- [ ] Yes
- [ ] No
- [x] N/A

Addresses dotnet/aspnetcore#31971
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-blazor Includes: Blazor, Razor Components
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants