Fix CanReadArrayOfAnySize timeout on checked coreclr by skipping the 2 GB case on slow runtimes

[Copilot]

EdgeCaseTests.CanReadArrayOfAnySize repeatedly times out (~14+ min) on the checked coreclr windows x64 Release CI leg. The 2 GB array case (Array.MaxLength = 2,147,483,591) was previously gated by #if RELEASE && NET, enabling it for Release library builds. However, checked coreclr's extra assertions/validation make processing a 2 GB array prohibitively slow.

Description

Instead of skipping all test cases on non-release runtimes, the fix adds a targeted in-method skip guard for only the 2 GB case. The #if RELEASE && NET preprocessor guard and [ConditionalTheory] are replaced with a plain [Theory] and a runtime check inside the method body:

[Theory]
[InlineData(100)]
[InlineData(64_001)]
[InlineData(127_000)]
[InlineData(2147483591)] // Array.MaxLength
public void CanReadArrayOfAnySize(int length)
{
    if (length == 2147483591 && (!PlatformDetection.Is64BitProcess || !PlatformDetection.IsReleaseRuntime || PlatformDetection.IsMonoRuntime))
    {
        throw new SkipTestException("It would take too much time to execute.");
    }
    // ...
}

The smaller cases (100, 64_001, 127_000) continue to run on all platforms and runtime configurations. The 2 GB case is skipped only when running on a non-64-bit process, a non-release (checked/debug) runtime, or Mono — where it would time out or be impractical.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>System.Formats.Nrbf.Tests.EdgeCaseTests.CanReadArrayOfAnySize times out on checked coreclr</issue_title>
<issue_description>## Build Information
Build: https://dev.azure.com/dnceng-public/public/_build/results?buildId=1348315
Leg Name: Libraries Test Run checked coreclr windows x64 Release

Error Message

{
    "ErrorMessage": ["CanReadArrayOfAnySize", "timed out"],
    "BuildRetry": false,
    "ExcludeConsoleLog": false
}

Description

System.Formats.Nrbf.Tests.EdgeCaseTests.CanReadArrayOfAnySize times out after 14+ minutes on the checked coreclr windows x64 Release leg. The test runs as a long-running test until the Helix work item is killed.

Helix log: https://helix.dot.net/api/2019-06-17/jobs/c6faf158-7c28-4acb-bec6-ddcc415ba5e5/workitems/System.Formats.Nrbf.Tests/console

Previous occurrence: #110285 (closed December 2024)

Pull request where observed: #125961 (codeflow update, unrelated to the failure)

Known issue validation

Build: 🔎 https://dev.azure.com/dnceng-public/public/_build/results?buildId=1348315
Error message validated: [CanReadArrayOfAnySize timed out]
Result validation: ✅ Known issue matched with the provided build.
Validation performed at: 3/23/2026 11:03:41 PM UTC

Report

Build	Definition	Test	Pull Request
1348938	dotnet/runtime	System.Formats.Nrbf.Tests.WorkItemExecution	#125881
1348882	dotnet/runtime	System.Formats.Nrbf.Tests.WorkItemExecution	#125174
1348844	dotnet/runtime	System.Formats.Nrbf.Tests.WorkItemExecution	#125129
1348773	dotnet/runtime	System.Formats.Nrbf.Tests.WorkItemExecution	#125983
1348315	dotnet/runtime	System.Formats.Nrbf.Tests.WorkItemExecution	#125961
1348754	dotnet/runtime	System.Formats.Nrbf.Tests.WorkItemExecution	#125981
1348752	dotnet/runtime	System.Formats.Nrbf.Tests.WorkItemExecution	#125083
1348706	dotnet/runtime	System.Formats.Nrbf.Tests.WorkItemExecution	#125439
1348612	dotnet/runtime	System.Formats.Nrbf.Tests.WorkItemExecution	#125973
1348585	dotnet/runtime	System.Formats.Nrbf.Tests.WorkItemExecution	#125835
1348578	dotnet/runtime	[System.Formats.Nrbf.Tests.WorkItemExecution](https://dev.azure.co...

• Fixes System.Formats.Nrbf.Tests.EdgeCaseTests.CanReadArrayOfAnySize times out on checked coreclr #125994

---

🔒 GitHub Advanced Security automatically protects Copilot coding agent pull requests. You can protect all pull requests by enabling Advanced Security for your repositories. Learn more about Advanced Security.

[Copilot]

Pull request overview

This PR updates a resource-intensive System.Formats.Nrbf test to avoid timing out when executed on non-Release runtimes (notably Checked CoreCLR), where additional runtime validation makes the existing workload too slow.

Changes:

• Add PlatformDetection.IsReleaseRuntime to the ConditionalTheory gating EdgeCaseTests.CanReadArrayOfAnySize, skipping it on Checked/Debug runtimes.

[adamsitnik]

@copilot apply my suggestion, but make sure it builds and tests are passing before you push the commit

[Copilot]

@copilot apply my suggestion, but make sure it builds and tests are passing before you push the commit

Applied in 6a4f571 — build confirmed clean (0 warnings, 0 errors).

[adamsitnik]

LGTM, thank you @danmoseley !

[github-actions]

🤖 Copilot Code Review — PR #126006

Holistic Assessment

Motivation: The PR addresses a real, frequently recurring CI timeout — CanReadArrayOfAnySize with the 2 GB Array.MaxLength case takes 14+ minutes on checked coreclr, killing the Helix work item. The linked issue (#125994) shows this hitting many unrelated PRs. The original #if RELEASE && NET compile-time guard was ineffective because it checks the library build configuration, not the runtime configuration — library tests build as Release even when the coreclr runtime is checked.

Approach: The fix replaces the compile-time guard with a runtime check using PlatformDetection.IsReleaseRuntime and PlatformDetection.IsNetCore, targeting only the 2 GB case. This follows the area owner's (@adamsitnik) explicit direction and matches established patterns in sibling test files (ArrayOfSerializationRecordsTests.cs, ArraySinglePrimitiveRecordTests.cs).

Summary: ✅ LGTM. The change is minimal, correct, and well-motivated. It fixes the CI timeout while preserving all smaller test cases across all configurations — and actually increases test coverage by removing the overly broad 64-bit attribute-level skip. The area owner has approved and the latest commit applies their final suggestion.

---

Detailed Findings

✅ Correctness — Skip logic is sound

The runtime skip guard correctly skips the 2 GB case when any of these conditions hold:

• !PlatformDetection.Is64BitProcess — cannot allocate a 2 GB array on 32-bit
• !PlatformDetection.IsReleaseRuntime — too slow on checked/debug runtimes (the root cause of the timeout)
• !PlatformDetection.IsNetCore — impractical on .NET Framework and Mono

These are OR'd, which is correct. The existing OOM catch (line 87–90) is preserved as a safety net for memory-constrained 64-bit release environments.

✅ Test coverage — Improved over baseline

The original [ConditionalTheory(typeof(PlatformDetection), nameof(PlatformDetection.Is64BitProcess))] skipped all four test cases on 32-bit. The new code only applies the skip to the 2 GB case, allowing the smaller cases (100, 64,001, 127,000) to run on 32-bit — a net gain in coverage.

✅ [ConditionalTheory] usage — Correct

Using [ConditionalTheory] without parameters (rather than plain [Theory]) is required to enable the custom test invoker that catches SkipTestException and reports tests as "skipped" instead of "failed". This was correctly identified by @danmoseley during review and matches sibling test patterns.

✅ !IsNetCore vs IsMonoRuntime — Correct final revision

The latest commit applies @adamsitnik's observation that these tests also run on .NET Framework, not just Mono. !PlatformDetection.IsNetCore (Environment.Version.Major >= 5 || ...StartsWith(".NET Core")) covers both Mono and .NET Framework, which is the correct broader guard.

✅ No public API changes

The change is test-only. No public API surface is affected.

Note

This review was generated by Copilot and reflects the latest revision (commit bae6537cc) which applies @adamsitnik's final suggestion.

Generated by Code Review for issue #126006 · ◷