[ci-scan] Test failure: browser-wasm - invalid value type 'exn', enable with --experimental-wasm-exnref

[github-actions]

Caution

agentic threat detected
Threat detection flagged this output in warn mode. Manual review is REQUIRED before any follow-up automation.

Details

The threat detection results could not be parsed.

Review the workflow run logs for details.

Build Analysis Known Build Error. Automated CI outer-loop scan detection.

Summary

On runtime-coreclr outerloop (definition 108), the browser-wasm CoreCLR test legs abort during WebAssembly module instantiation before any test executes. The V8 engine on the CoreCLR WASM Helix queue does not enable the exnref proposal, so WebAssembly.instantiate() rejects the exn value type baked into the runtime module.

This is a post-close recurrence of the exnref engine bump tracker #129849 ([browser] Use the new version of V8 with exnref), which was closed as completed on 2026-07-11T03:19Z. Both the source and follow-up builds below finished after that close, and the CoreCLR (not Mono) browser-wasm leg still fails — the CoreCLR Helix queue image digest in eng/pipelines/coreclr/templates/helix-queues-setup.yml appears not to have picked up the exnref-capable V8 image.

Signature

failed to asynchronously prepare wasm: CompileError: WebAssembly.instantiate(): invalid value type 'exn', enable with --experimental-wasm-exnref @+58
Aborted(CompileError: WebAssembly.instantiate(): invalid value type 'exn', enable with --experimental-wasm-exnref @+58)
RuntimeError: Aborted(CompileError: WebAssembly.instantiate(): invalid value type 'exn', enable with --experimental-wasm-exnref @+58)

Occurrences

• Pipeline: runtime-coreclr outerloop (definition 108), branch main
• Leg/queue: browser-wasm (CoreMangLib and other CoreCLR test work items)
• Source build: 1504535
• Follow-up build: 1504742 (signature reproduces — 3 hits in the CoreMangLib console)
• First build it occurred: within the scanned window; recurrence post-dates the close of [browser] Use the new version of V8 with exnref #129849 (2026-07-11T03:19Z)

Root cause / mitigation reference

Root cause and full remediation steps (Helix queue image digest bump to an exnref-capable V8, BrowserVersions.props bump) are documented in #129849. The CoreCLR outerloop browser-wasm queue still runs the old engine.

Related: #129849

{
  "ErrorMessage": "invalid value type 'exn', enable with --experimental-wasm-exnref",
  "BuildRetry": false,
  "ExcludeConsoleLog": false
}

Generated by CI Outer-Loop Failure Scanner · 529.2 AIC · ⊞ 19.5K · ◷

Report

Build	Repository	Test	Pull Request
1504571	dotnet/runtime	tracing.WorkItemExecution	#130408
1504653	dotnet/runtime	tracing.WorkItemExecution	#130444
1505406	dotnet/runtime	tracing.WorkItemExecution	#130597
1504486	dotnet/runtime	tracing.WorkItemExecution	#99200
1504189	dotnet/runtime	tracing.WorkItemExecution	#130535
1503815	dotnet/runtime	tracing.WorkItemExecution	#130509
1504279	dotnet/runtime	tracing.WorkItemExecution	#130506
1504235	dotnet/runtime	tracing.WorkItemExecution	#130536

Summary

24-Hour Hit Count	7-Day Hit Count	1-Month Count
1	8	8

Known issue validation

Build: 🔎
Result validation: ⚠️ Validation could not be done without an Azure DevOps build URL on the issue. Please add it to the "Build: 🔎" line.
Validation performed at: 7/15/2026 2:34:29 PM UTC

[JulieLeeMSFT]

CC @lewing.

[dotnet-policy-service]

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

[pavelsavara]

Did my #130550 fixed it or there is yet another place ?