Tagging subscribers to this area: @maryamariyan, @carlossanlop
See info in area-owners.md if you want to be subscribed.

I can now see two relevant CI legs being queued for this PR:

• runtime (CoreCLR Product Build windows arm64 release)
• runtime (Libraries Build windows arm64 Release)

I mention them because it seems the original PR that introduced this unit test did not run it in arm64, hence why the failure was not detected until later.

I believe those are builds but not tests. I saw the same run in the original PR but the tests were not executed. It's understood why that happens. There are other workflows that are not PR validation, however, that do expect libraries tests to run on arm64 (Bruce's JIT stress runs I think).

Ah ok, good to know. Thanks.

Exactly: there are 3 JIT stress pipelines that run libraries tests in many stress variations against a Checked coreclr on all platforms:

https://dev.azure.com/dnceng/public/_build?definitionId=833
https://dev.azure.com/dnceng/public/_build?definitionId=668
https://dev.azure.com/dnceng/public/_build?definitionId=669

Note also that these are the only runs (I believe) that run the libraries tests with the JIT in optimization mode (namely, tiered compilation disabled: COMPlus_TieredCompilation=0). That has been a separate worry for a long time.