[browser][coreCLR] RuntimeAsync AsyncProfilerTests FailFast crashes System.Threading.Tasks.Tests (IsRuntimeAsyncSupported gate doesn't exclude browser) #132311

Description

On browser-wasm CoreCLR, one of the AsyncProfilerTests runtime-async "unhandled exception" tests crashes the process via Environment.FailFast instead of the exception being observed/caught. Because it's a FailFast, the entire System.Threading.Tasks.Tests work item dies with no xUnit results — so it also masks any other failures in that assembly.

Observed on the LibraryTestsCoreCLR_SmokeFirefoxV8 legs of the R2R bring-up PR #129634 (build 1551759, head d3f76ed6), on V8 and Firefox, exit code 71.

console.error: Process terminated.
console.error: ThreadPool.BackgroundJobHandler failed
   at System.Environment.FailFast(StackCrawlMark ByRef, String, Exception, String)
   at System.Environment.FailFast(String, Exception)
   at System.Threading.ThreadPool.BackgroundJobHandler()
console.error: System.InvalidOperationException: deep unhandled
   at System.Threading.Tasks.Tests.AsyncProfilerTests.RuntimeAsync_DeepUnhandledInnerThrows()
WASM EXIT 1

Tests that started right before the crash (from the console): RuntimeAsync_CallstackSimulation_UnhandledException, RuntimeAsync_CustomSyncContext_EmitsContextEventsAndCallstack, StateMachineAsync_KeywordGatekeeping. The throwing frame belongs to the RuntimeAsync_UnhandledExceptionUnwind chain: ..._Marker -> RuntimeAsync_DeepUnhandledOuter -> RuntimeAsync_DeepUnhandledMiddle -> RuntimeAsync_DeepUnhandledInnerThrows (which does await Task.Yield(); throw new InvalidOperationException("deep unhandled");), and is expected to be caught by RuntimeAsync_UnhandledExceptionUnwind_Catcher_Marker's try/catch (InvalidOperationException) (src/libraries/System.Runtime/tests/System.Threading.Tasks.Tests/System.Runtime.CompilerServices/AsyncProfilerV2Tests.cs).

Primary hint — the test gate does not match the build gate

The runtime-async compiler feature (Features=…;runtime-async=on) is enabled per the MSBuild RuntimeAsyncSupported property, which excludes browser/wasi/android/apple-mobile/Mono (eng/testing/tests.targets, src/libraries/Directory.Build.targets):

<RuntimeAsyncSupported Condition="'$(TargetOS)' != 'browser'
  and '$(TargetOS)' != 'wasi'
  and '$(TargetOS)' != 'android'
  and '$(TargetsAppleMobile)' != 'true'
  and '$(RuntimeFlavor)' != 'Mono'">true</RuntimeAsyncSupported>

But the test-time gate does not exclude browser (src/libraries/Common/tests/TestUtilities/System/PlatformDetection.cs:477):

public static bool IsRuntimeAsyncSupported => !IsMonoRuntime;

IsMonoRuntime is false on browser CoreCLR, so IsRuntimeAsyncSupported is true and every [ConditionalFact(nameof(IsRuntimeAsyncSupported))] in AsyncProfilerTests runs on a build where the runtime-async feature was not turned on. That inconsistency (test gate !IsMonoRuntime vs. build gate that excludes browser) is the most likely reason these tests execute on browser CoreCLR at all, and is the first thing to check.

Mechanism

The exception is thrown after await Task.Yield(), i.e. on the resumed continuation, which on single-threaded wasm runs on the ThreadPool.BackgroundJobHandler pump. Instead of being propagated back into the awaiting Task (and caught by the enclosing try/catch), it escapes as an unhandled thread-pool exception, which correctly triggers Environment.FailFast. So either:

• the continuation-resume path isn't wrapping the body in the exception-capturing handler on browser CoreCLR (a runtime bug if runtime-async is meant to work here), or
• the methods aren't actually getting runtime-async codegen on browser (feature off), and the test's expectations/exception plumbing don't hold — in which case the test simply shouldn't run here.

Suggested independent-triage steps

1. Confirm whether runtime-async=on is applied to System.Threading.Tasks.Tests for TargetOS=browser (per the targets above it should be off). If off, these [RuntimeAsyncMethodGeneration(true)] methods don't get runtime-async semantics, and the unwind/EventPipe expectations don't apply.
2. Fastest CI unblock: align the test gate with the build — make PlatformDetection.IsRuntimeAsyncSupported also exclude browser/wasi/android (mirror the MSBuild RuntimeAsyncSupported predicate), or [ActiveIssue]-skip the AsyncProfilerTests runtime-async tests on browser. This also stops the FailFast from masking the rest of System.Threading.Tasks.Tests.
3. If runtime-async is intended on browser CoreCLR: reproduce a minimal [RuntimeAsyncMethodGeneration(true)] async Task M() { await Task.Yield(); throw new InvalidOperationException(); } awaited under a try/catch, and check whether the exception is delivered to the catch or leaks to ThreadPool.BackgroundJobHandler. DOTNET_RuntimeAsync=1 is the runtime feature switch used by the coreclr runtime-async tests.
4. Note the blast radius: because this FailFasts, the whole System.Threading.Tasks.Tests assembly reports no results; fixing the gate/crash may reveal or clear additional failures in that suite.

Configuration

• -os browser -a wasm, CoreCLR, Release; V8 and Firefox.
• CoreCLR-on-browser specific; not observed on Mono (where IsRuntimeAsyncSupported is already false).