Blazorwasm hot-reload breaks if changes are made before socket is connected

[Blackclaws]

Describe the bug

dotnet watch hot-reload functionality breaks for blazorwasm projects when changes are made before the dotnet reload socket is connected

Only a restart of dotnet watch will restore functionality

This is much easier to reproduce using firefox which takes a long time to establish the socket for some reason

To Reproduce

1. dotnet new blazorwasm
2. Add "hotReloadProfile" : "blazorwasm" to launchSettings.json
3. dotnet watch
4. Change index.razor or any other file in a hot reload supported way before the dotnet reload socket has been connected (see browser log)
5. See nothing change on the page but dotnet watch report "Hot Reload of changes succeeded"
6. Wait for the socket to finish connecting
7. See no changes appear
8. Further changes to source files break in the webapp with an exception

Exceptions in JS Console

console.trace() * Assertion at /__w/1/s/src/mono/mono/metadata/metadata.c:1151, condition `<disabled>' not met
* Assertion at /__w/1/s/src/mono/mono/metadata/metadata.c:1151, condition `<disabled>' not met
Uncaught 
Object { name: "ExitStatus", message: "Program terminated with exit(0)", status: 0 }
​
message: "Program terminated with exit(0)"
​
name: "ExitStatus"

status: 0

Further technical details

• Include the output of dotnet --info

.NET SDK (reflecting any global.json):
 Version:   6.0.100-preview.3.21202.5
 Commit:    aee38a6dd4

Runtime Environment:
 OS Name:     arch
 OS Version:  
 OS Platform: Linux
 RID:         arch-x64
 Base Path:   /usr/share/dotnet/sdk/6.0.100-preview.3.21202.5/

Host (useful for support):
  Version: 6.0.0-preview.3.21201.4
  Commit:  236cb21e3c

.NET SDKs installed:
  5.0.102 [/usr/share/dotnet/sdk]
  5.0.202 [/usr/share/dotnet/sdk]
  6.0.100-preview.3.21202.5 [/usr/share/dotnet/sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.All 2.1.18 [/usr/share/dotnet/shared/Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.1.18 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.1.11 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 5.0.0-rc.2.20475.17 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 5.0.2 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 5.0.5 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 6.0.0-preview.3.21201.13 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 2.0.9 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.18 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.1.11 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 5.0.0-rc.2.20475.5 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 5.0.2 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 5.0.5 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 6.0.0-preview.3.21201.4 [/usr/share/dotnet/shared/Microsoft.NETCore.App]

Browser: Firefox

[captainsafia]

In .NET 6 Preview 4, we pushed a fix that prevents dotnet watch from reporting changes as successfully applied if the browser did not acknowledge it.

Marking as investigate to determine why it might be taking a while for the connection to be established on Firefox.

Thanks for contacting us.
We're moving this issue to the Next sprint planning milestone for future evaluation / consideration. Because it's not immediately obvious that this is a bug in our framework, we would like to keep this around to collect more feedback, which can later help us determine the impact of it. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.