/ba-g failures in WasmBuildTests are unrelated

Is there a workaround or timeframe to receive this?

@revbones-dev it will be released with 10.0.2.

In the meantime you could manually update the URLs similar to what I do in this PR in the dotnet.runtime.js.map and dotnet.js.map files in the wwwroot/_framework folder in the output folder and do a hard refresh.

Edit: maybe this is OK, because the preview bits are built from internal repo with different hash.

I was validating this by looking at the Microsoft.NETCore.App.Runtime.Mono.browser-wasm.10.0.2.nupkg of the preview binaries.

It contains file runtimes\browser-wasm\native\dotnet.diagnostics.js.map contains link to
https://raw.githubusercontent.com/dotnet/dotnet/a2aab71e7e1038d6304a5e1675c39392ced29691/src/runtime/src/mono/browser/runtime/diagnostics/logging.ts

But that resolves to HTTP 404.

This is likely because it was built from local commit that was not pushed to github. Or it’s githash from another repository.
Changing the hash in the URL to last hash on https://github.com/dotnet/dotnet/commits/release/10.0.102/ makes it work.

https://raw.githubusercontent.com/dotnet/dotnet/a1b9d991e4596823841f4f9d840e72ac369e3a7e/src/runtime/src/mono/browser/runtime/diagnostics/logging.ts

I think this is not critical enough to stop 10.0.2 rollout, but it would be nice to fix eventually.

Yes that's expected right now, we'll merge the internal branch to public shortly after release and then the commit will resolve.