Fix streaming SSR timing issue

[SteveSandersonMS]

Fix streaming SSR timing issue

On certain rare occasions, streaming SSR could produce a blank page due to a timing issue.

Description

If a page component:

• Has @attribute [StreamRendering]
• Is being visited through enhanced navigtion
• Has an OnInitializedAsync whose returned task is not pre-completed but does complete very quickly (e.g., await Task.Yield())

... then there was a race condition. On rare occasions (seems to be about 1 in 20 page loads), the result would be a blank page. This didn't show up in our E2E tests because they always wait for fairly long async tasks so that the browser automation had time to observe the loading states. This PR adds a new E2E test that does recreate the issue and reliably fails - it does many, many page loads and basically always hits the problem at least once without the fix included here.

Fixes #51345

Customer Impact

Without this fix, a particular combination of features would be unreliable.

Regression?

• Yes
• No

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

Risk

• High
• Medium
• Low

The only change is to fix what is definitely a bug. It's hard to see how this would have a negative effect, as no other code is built on top of this. It's not a public API - it's just part of how the Razor Components endpoint works.

Verification

• Manual (required)
• Automated

Packaging changes reviewed?

• Yes
• No
• N/A

[ghost]

Hi @SteveSandersonMS. Please make sure you've updated the PR description to use the Shiproom Template. Also, make sure this PR is not marked as a draft and is ready-to-merge.

To learn more about how to prepare a servicing PR click here.

[surayya-MS]

Looks good to me!

[mkArtakMSFT]

Thanks Steve.

Good idea to also include the comment in the SendStreamingUpdateAsync method.

[ghost]

Hi @SteveSandersonMS. This PR was just approved to be included in the upcoming servicing release. Somebody from the @dotnet/aspnet-build team will get it merged when the branches are open. Until then, please make sure all the CI checks pass and the PR is reviewed.

[mkArtakMSFT]

@SteveSandersonMS I think I've messed up my local git repo, so here how I ended up updating the blazor.web.js file.

1. created a new branch off of release/8.0.
2. Cherry-picked your first three commits onto it.
3. Generated the blazor.web.js using npm run build in the Components\Web.JS folder
4. Used the GitHub conflict resolution editor and pasted the full content of locally generated blazor.web.js into the editor (replacing all content).

I believe it's good, but wanted to get confirmation from you before merging.

By the way, do we have tests that would fail if this file is generated incorrectly?

[SteveSandersonMS]

Used the GitHub conflict resolution editor and pasted the full content of locally generated blazor.web.js into the editor (replacing all content).

That sounds a bit suspicious as it should not have a merge conflict at all if it's been rebased. So just in case, I've regenerated it and force-pushed an update. This should be OK to merge now.

By the way, do we have tests that would fail if this file is generated incorrectly?

We used to but they got disabled. I filed an issue last September asking for those tests to be re-enabled but it doesn't look like that's yet been done: #43715