Fix race condition in AssetCachingTests and re-enable test

[Copilot]

Description

The BlazorApp_BasedOnFingerprinting_LoadsWasmAssetsFromCache test reassigned counterLoaded inside the Test lambda after OnConsoleMessage captured it in a closure, causing the handler to potentially signal the wrong task.

Fixed by:

• Split single counterLoaded into firstCounterLoaded and secondCounterLoaded (no reassignment)
• Added thread-safe loadCount counter using Interlocked.Increment
• Handler now checks count: 1 completes first task, 2 completes second task
• Removed [ActiveIssue] attribute to re-enable the test

// Before: Race condition from reassignment
var counterLoaded = new TaskCompletionSource();
OnConsoleMessage = (type, msg) => {
    if (msg.Contains("Counter.OnAfterRender"))
        counterLoaded.SetResult();  // Captures counterLoaded
},
Test = async (page) => {
    await counterLoaded.Task;
    counterLoaded = new();  // ⚠️ Reassignment breaks closure
    await counterLoaded.Task;
}

// After: Separate tasks, no reassignment
var firstCounterLoaded = new TaskCompletionSource();
var secondCounterLoaded = new TaskCompletionSource();
var loadCount = 0;
OnConsoleMessage = (type, msg) => {
    if (msg.Contains("Counter.OnAfterRender")) {
        var count = Interlocked.Increment(ref loadCount);
        if (count == 1) firstCounterLoaded.SetResult();
        else if (count == 2) secondCounterLoaded.SetResult();
    }
},
Test = async (page) => {
    await firstCounterLoaded.Task;
    await page.ReloadAsync();
    await secondCounterLoaded.Task;
}

Customer Impact

Intermittent test failures blocking CI/CD pipelines. No customer-facing runtime impact.

Regression

No. Pre-existing concurrency bug in test infrastructure.

Testing

Code review verified closure semantics and thread-safety. Test is now re-enabled and will run in CI to validate stability.

Risk

Low. Test-only change, 7 net lines added. Logic simplified by eliminating variable reassignment. Test re-enabled after fixing race condition.

Original prompt

The AssetCachingTests.BlazorApp_BasedOnFingerprinting_LoadsWasmAssetsFromCache test currently reassigns the counterLoaded TaskCompletionSource variable inside its Test lambda, which may cause a race condition: multiple invocations can capture the wrong task in the closure, leading to failures like:

at System.Collections.Generic.List`1.Enumerator.MoveNext()
at Wasm.Build.Tests.Blazor.AssetCachingTests.<>c__DisplayClass1_0.<<BlazorApp_BasedOnFingerprinting_LoadsWasmAssetsFromCache>b__1>d.MoveNext() in /_/src/mono/wasm/Wasm.Build.Tests/Blazor/AssetCachingTests.cs:line 76
...

This problem is due to re-initializing counterLoaded while closures to the previous instance are still in use in the OnConsoleMessage lambda. The fix is to:

• Declare counterLoaded at a broader scope, accessible to both lambdas.
• Before each awaited navigation, assign a new TaskCompletionSource and ensure OnConsoleMessage sets the result for the currently-scoped object.

This eliminates the chance that OnConsoleMessage is signaling a stale or wrong TCS instance and resolves the race condition and intermittent failures likely caused by this bug.

This pull request was created from Copilot chat.

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[lewing]

interestingly

runtime/src/mono/wasm/Wasm.Build.Tests/Blazor/AssetCachingTests.cs

Line 26 in 01819d3

[ActiveIssue("https://github.com/dotnet/runtime/issues/122338")] // add it back to eng\testing\scenarios\BuildWasmAppsJobsList.txt