[pavelsavara]

Summary

Recover from unusable browser HTTP-cache entries for fingerprinted boot resources by changing the existing download retries to cache: "reload", rather than adding a second recovery/retry mechanism.

This is an alternative to #135925. Server-side prevention for missing manifest assets is in dotnet/aspnetcore#70062.

• Leave healthy force-cache requests unchanged.
• Promote failed force-cache downloads to reload before applying terminal-status handling. A cached 404 gets a network recovery attempt; a visible 404 from that recovery remains terminal.
• Retain the existing maximum of three attempts, scheduling and delay, and honor enableDownloadRetry=false.
• Allow cached main-Wasm failures to recover, with bootstrap priority so retries cannot wait behind assembly download slots that require its memory.
• Preserve native symbols' no-retry behavior. Startup awaits symbols before queuing the other downloads, so putting a failed symbol fetch behind the download-queue barrier would deadlock.
• Reject explicitly empty cached binary responses and empty buffered bodies without adding streaming-body reads. Preserve valid empty VFS/symbol resources.
• Consume buffered error responses without retaining them as successful asset buffers, and release failed streaming-download slots.
• Chain Mono's progress promise and report each resource once to avoid stray unhandled rejections or progress beyond the total.

Browser coverage

The cache-recovery matrix uses the static cache-seed.html page and hosted test server to seed real, cacheable invalid responses. Chrome starts the application using the ordinary loader and HTTP cache; no Playwright routing substitutes those responses.

The matrix covers empty responses, cached 404s, integrity mismatches, integrity checking disabled, transient and permanent reload failures, terminal reload 404s, disabled retries, ordinary no-cache requests, buffered ICU data, and main-Wasm recovery with default scheduling and one download slot. It checks exact fetch modes, attempt counts, server requests, startup outcome, and progress bounds. Assembly selection follows UseWebcil, covering Webcil and DLL resources.

Small client-assembly cache reuse is asserted on the following boot. Large Debug native-Wasm cache retention is discretionary; those cases instead verify startup, retry modes/counts, scheduling, and one healthy force-cache attempt on the following boot with at most one network request. Earlier non-fingerprinted healthy-cache controls also verified conditional revalidation (304).

The generated client explicitly selects the current built runtime and SDK packs, even when Blazor targets the previous framework. CoreCLR uses the existing client-configuration helper. Mono imports UseCurrentMonoRuntime.targets into the copied client and sets WBTMonoRuntimePackVersion; the test no longer embeds the MSBuild target in C#. The shared client project remains unchanged.

Every recovery case verifies resolved runtime-pack identity/version and loader bytes against an independent extracted SDK pack when available, or against the local nupkg if the pack is absent or would compare a file with itself. An extracted-pack comparison checks SDK agreement, not package freshness. Runtime packages and constructed SDKs were rebuilt after the .NET 12 transition to avoid an old manifest incorrectly mapping net11.0 to the current package.

Separate ModuleConfigTests.NativeSymbolsDownloadDoesNotHang cases publish an actual fingerprinted native symbol map and require the diagnostics module. A fetch wrapper injects HTTP 404s and rejected network requests. The five cases check required/optional failures and healthy startup, assert exactly one force-cache symbol attempt, and verify startup succeeds or fails rather than hanging. Optional HTTP failures permit startup; rejected fetches preserve their previous fatal-error behavior.

Validation

Full Debug browser baselines were previously built for both runtimes. The following latest validation was run locally on November 2, 2026, from the corresponding CoreCLR or Mono worktree root, using:

$env:NuGetAudit='false'
$env:UseSharedCompilation='false'
$env:SKIP_PROJECT_CLEANUP='1'

Latest review follow-up

The native-symbol HTTP 404 and network-failure cases both reproduced the startup hang against the unfixed local CoreCLR runtime: one force-cache attempt, followed by a 10-second timeout waiting for WASM EXIT.

.\dotnet.cmd build -bl /p:TargetOS=browser /p:TargetArchitecture=wasm /p:RuntimeFlavor=CoreCLR /p:Configuration=Debug /p:EnableHotReloadInRuntimeConfigDevFile=false /p:InstallChromeForTests=false /p:TestUsingWorkloads=true /p:InstallWorkloadForTesting=false /p:XUnitMethodName=Wasm.Build.Tests.ModuleConfigTests.NativeSymbolsDownloadDoesNotHang /t:Test .\src\mono\wasm\Wasm.Build.Tests

Result before the loader fix: failed as expected: both required-symbol failure cases timed out. These reached the symbol fetch; they were not SDK/restore/setup failures.

Rebuilt the affected CoreCLR browser runtime/native outputs and packages:

.\build.cmd -bl -os browser -subset clr.runtime+clr.corelib+libs.native+host.native+libs.pretest+packs -c Debug /p:RuntimeFlavor=CoreCLR /p:EnableHotReloadInRuntimeConfigDevFile=false

Result: passed. Verified that the new runtime nupkg contains the fixed retry gate.

Recreated the constructed workload SDK from those artifacts:

.\dotnet.cmd build -bl /p:TargetOS=browser /p:TargetArchitecture=wasm /p:RuntimeFlavor=CoreCLR /p:Configuration=Debug /p:EnableHotReloadInRuntimeConfigDevFile=false /p:TestUsingWorkloads=true /t:InstallWorkloadUsingArtifacts .\src\mono\wasm\Wasm.Build.Tests

Result: passed.

Ran the five symbol cases and full CoreCLR cache matrix together in real Chrome:

.\dotnet.cmd build -bl /p:TargetOS=browser /p:TargetArchitecture=wasm /p:RuntimeFlavor=CoreCLR /p:Configuration=Debug /p:EnableHotReloadInRuntimeConfigDevFile=false /p:InstallChromeForTests=false /p:TestUsingWorkloads=true /p:InstallWorkloadForTesting=false '/p:XUnitMethodName=Wasm.Build.Tests.ModuleConfigTests.NativeSymbolsDownloadDoesNotHang -method Wasm.Build.Tests.Blazor.AssetCachingTests.*' /t:Test .\src\mono\wasm\Wasm.Build.Tests

Result: 22 passed, 0 failed, 0 skipped, including all five symbol cases and all 17 cache cases. Native-Wasm cache recovery still works with default and one-slot scheduling.

Validated the extracted Mono runtime-selection target using the previously refreshed Mono workload SDK:

.\dotnet.cmd build -bl /p:TargetOS=browser /p:TargetArchitecture=wasm /p:RuntimeFlavor=Mono /p:Configuration=Debug /p:EnableHotReloadInRuntimeConfigDevFile=false /p:InstallChromeForTests=false /p:TestUsingWorkloads=true /p:InstallWorkloadForTesting=false /p:XUnitClassName=Wasm.Build.Tests.Blazor.AssetCachingTests /t:Test .\src\mono\wasm\Wasm.Build.Tests

Result: 17 passed, 0 failed, 0 skipped (Mono, Webcil).

.\dotnet.cmd build -bl /p:TargetOS=browser /p:TargetArchitecture=wasm /p:RuntimeFlavor=Mono /p:Configuration=Debug /p:EnableHotReloadInRuntimeConfigDevFile=false /p:InstallChromeForTests=false /p:TestUsingWorkloads=true /p:InstallWorkloadForTesting=false /p:WasmEnableWebcil=false /p:XUnitClassName=Wasm.Build.Tests.Blazor.AssetCachingTests /t:Test .\src\mono\wasm\Wasm.Build.Tests

Initial result: 16 passed, 1 failed, 0 skipped (Mono, DLL). All recovery rows passed. The existing healthy-cache control timed out on its first cold load; its native-Wasm HTTP transfer took about 27 seconds against a 30-second startup deadline.

Reran that unchanged control in isolation:

.\dotnet.cmd build -bl /p:TargetOS=browser /p:TargetArchitecture=wasm /p:RuntimeFlavor=Mono /p:Configuration=Debug /p:EnableHotReloadInRuntimeConfigDevFile=false /p:InstallChromeForTests=false /p:TestUsingWorkloads=true /p:InstallWorkloadForTesting=false /p:WasmEnableWebcil=false /p:XUnitMethodName=Wasm.Build.Tests.Blazor.AssetCachingTests.BlazorApp_BasedOnFingerprinting_LoadsWasmAssetsFromCache /t:Test .\src\mono\wasm\Wasm.Build.Tests

Result: 1 passed, 0 failed, 0 skipped. No timeout increase, suppression, or test disabling was added. Across these runs, all 56 distinct selected cases passed, but the initial DLL matrix was not entirely green.

Loader ESLint, test-JavaScript syntax checking, shared-target XML parsing, and git diff --check also passed.

Local prerequisites and scope

• EnableHotReloadInRuntimeConfigDevFile=false is a command-line-only workaround for an unrelated SDK DotNetWatch static-assets endpoint mismatch.
• NuGetAudit=false was set only in the local test-command environment because the existing fixture's pinned dependencies produce audit warnings as errors. No package-version change or audit suppression is included.
• UseSharedCompilation=false avoids compiler-server locks while refreshing the isolated SDKs.
• Applications use the prebuilt runtime host; this PR does not change application relinking or per-app R2R code. No multithreaded, Firefox, or service-worker scenarios were run.

Resolves dotnet/aspnetcore#69488

Note

This PR and its description were implemented/updated with GitHub Copilot. The listed builds and tests were run locally.

[azure-pipelines]

Azure Pipelines:
Successfully started running 4 pipeline(s).
12 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[dotnet-policy-service]

Tagging subscribers to 'arch-wasm': @lewing, @pavelsavara
See info in area-owners.md if you want to be subscribed.