Fix CanReadArrayOfAnySize timeout on checked coreclr by skipping the 2 GB case on non-release 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] with platform conditions are replaced with [ConditionalTheory] (no parameters, to allow SkipTestException to be treated as a skip rather than a failure) and a runtime check inside the method body:

[ConditionalTheory][InlineData(100)][InlineData(64_001)][InlineData(127_000)][InlineData(2147483591)]// Array.MaxLengthpublicvoidCanReadArrayOfAnySize(intlength){if(length==2147483591&&(!PlatformDetection.Is64BitProcess||!PlatformDetection.IsReleaseRuntime||!PlatformDetection.IsNetCore)){thrownewSkipTestException("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:

• The process is not 64-bit, or
• The runtime is not a release runtime (!IsReleaseRuntime, which covers both checked and debug coreclr of any bitness), or
• The runtime is not .NET Core (i.e. running on .NET Framework)

!PlatformDetection.IsReleaseRuntime is used instead of SlowRuntimeTimeoutModifier != 1 because SlowRuntimeTimeoutModifier returns 1 for checked (non-release, non-debug) builds, meaning it would not correctly skip the 2 GB test case on checked runtimes.

Using [ConditionalTheory] without parameters (instead of plain [Theory]) ensures that SkipTestException is correctly treated as a skip rather than a test failure.

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...

• FixesSystem.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, recurring CI timeout — CanReadArrayOfAnySize with the 2 GB Array.MaxLength case takes 14+ minutes on the checked coreclr windows x64 Release leg, killing the Helix work item. The original #if RELEASE && NET compile-time guard was ineffective because it checks the library build configuration (always Release), not the runtime configuration. The fix is well-motivated.

Approach: Replacing the compile-time guard with a runtime skip is the right approach, and using [ConditionalTheory] (no parameters) to enable SkipTestException handling is correct. However, the specific runtime condition has a gap that prevents it from fixing the reported issue.

Summary: ❌ Needs Changes. The skip condition uses PlatformDetection.SlowRuntimeTimeoutModifier != 1, but SlowRuntimeTimeoutModifier returns 1 for Checked runtimes on x64 — the exact configuration that's timing out. The 2 GB test case will still run and timeout on checked coreclr x64.

---

Detailed Findings

❌ Skip condition does not fire on checked coreclr x64 — the reported CI leg

The condition at line 71:

if(length==2147483591&&(!PlatformDetection.Is64BitProcess||PlatformDetection.SlowRuntimeTimeoutModifier!=1||!PlatformDetection.IsNetCore))

On checked coreclr windows x64 (the failing CI leg):

Sub-condition	Value	Reason
!Is64BitProcess	false	It's x64
SlowRuntimeTimeoutModifier != 1	false	See trace below
!IsNetCore	false	It's .NET Core

Result: true && (false \|\| false \|\| false) → false — test is NOT skipped, timeout persists.

SlowRuntimeTimeoutModifier trace for Checked runtime on x64:

if(IsReleaseRuntime)// false — it's Checkedreturn1;if(IsRiscV64Process)// false — it's x64returnIsDebugRuntime?10:2;elsereturnIsDebugRuntime?5:1;// IsDebugRuntime is false (Checked ≠ Debug) → returns 1

The three runtime modes (Debug, Checked, Release) are mutually exclusive via AssemblyConfigurationEquals. A Checked runtime is neither Debug nor Release, so SlowRuntimeTimeoutModifier falls through to the else branch and returns 1 — the same as Release.

Note: SlowRuntimeTimeoutModifier's own doc comment says "For use as needed on tests that time out when run on a Debug or Checked runtime", but the implementation doesn't account for Checked on non-RISC-V. That appears to be a pre-existing gap in SlowRuntimeTimeoutModifier itself.

Suggested fix — revert to @adamsitnik's first suggestion which correctly handled this:

if(length==2147483591&&(!PlatformDetection.Is64BitProcess||!PlatformDetection.IsReleaseRuntime||!PlatformDetection.IsNetCore))

Or, if SlowRuntimeTimeoutModifier is preferred, fix it first to return > 1 for Checked runtimes (e.g., return IsDebugRuntime ? 5 : IsCheckedRuntime ? 2 : 1;).

(This finding was independently confirmed by both Claude Opus 4.6 and GPT-5.4.)

✅ [ConditionalTheory] without parameters — Correct

Changing from [ConditionalTheory(typeof(PlatformDetection), nameof(PlatformDetection.Is64BitProcess))] to bare [ConditionalTheory] is correct:

• The old attribute skipped all test cases (100, 64K, 127K) on 32-bit, which was unnecessarily restrictive — those small arrays work fine on 32-bit.
• The 32-bit guard is now applied only to the 2 GB case via the in-method check.
• [ConditionalTheory] (vs plain [Theory]) is required for SkipTestException to be reported as a skip rather than a failure, as @danmoseley correctly identified.

✅ Smaller test cases now run on all platforms — Good improvement

The smaller InlineData cases (100, 64_001, 127_000) are no longer gated by #if or 64-bit conditions, expanding test coverage.

Note

This review was generated by Copilot (Claude Opus 4.6), with a parallel review from GPT-5.4.

Generated by Code Review for issue #126006 · ◷

[danmoseley]

@copilot address feedback

[danmoseley]

@copilot it needs to skip on all checked runtimes whatever bitness. See text above

[Copilot]

@copilot it needs to skip on all checked runtimes whatever bitness. See text above

Fixed in ff355fb. SlowRuntimeTimeoutModifier returns 1 for checked builds (it only returns >1 for debug), so it didn't catch the timeout case. Switched to !PlatformDetection.IsReleaseRuntime which correctly skips on checked and debug runtimes of any bitness.

[danmoseley]

/ba-g one issue opened, the others "cffi_backend" already have issue

[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] with platform conditions are replaced with [ConditionalTheory] (no parameters, to allow SkipTestException to be treated as a skip rather than a failure) and a runtime check inside the method body:

[ConditionalTheory][InlineData(100)][InlineData(64_001)][InlineData(127_000)][InlineData(2147483591)]// Array.MaxLengthpublicvoidCanReadArrayOfAnySize(intlength){if(length==2147483591&&(!PlatformDetection.Is64BitProcess||!PlatformDetection.IsReleaseRuntime||!PlatformDetection.IsNetCore)){thrownewSkipTestException("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:

• The process is not 64-bit, or
• The runtime is not a release runtime (!IsReleaseRuntime, which covers both checked and debug coreclr of any bitness), or
• The runtime is not .NET Core (i.e. running on .NET Framework)

!PlatformDetection.IsReleaseRuntime is used instead of SlowRuntimeTimeoutModifier != 1 because SlowRuntimeTimeoutModifier returns 1 for checked (non-release, non-debug) builds, meaning it would not correctly skip the 2 GB test case on checked runtimes.

Using [ConditionalTheory] without parameters (instead of plain [Theory]) ensures that SkipTestException is correctly treated as a skip rather than a test failure.

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...

• FixesSystem.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, recurring CI timeout — CanReadArrayOfAnySize with the 2 GB Array.MaxLength case takes 14+ minutes on the checked coreclr windows x64 Release leg, killing the Helix work item. The original #if RELEASE && NET compile-time guard was ineffective because it checks the library build configuration (always Release), not the runtime configuration. The fix is well-motivated.

Approach: Replacing the compile-time guard with a runtime skip is the right approach, and using [ConditionalTheory] (no parameters) to enable SkipTestException handling is correct. However, the specific runtime condition has a gap that prevents it from fixing the reported issue.

Summary: ❌ Needs Changes. The skip condition uses PlatformDetection.SlowRuntimeTimeoutModifier != 1, but SlowRuntimeTimeoutModifier returns 1 for Checked runtimes on x64 — the exact configuration that's timing out. The 2 GB test case will still run and timeout on checked coreclr x64.

---

Detailed Findings

❌ Skip condition does not fire on checked coreclr x64 — the reported CI leg

The condition at line 71:

if(length==2147483591&&(!PlatformDetection.Is64BitProcess||PlatformDetection.SlowRuntimeTimeoutModifier!=1||!PlatformDetection.IsNetCore))

On checked coreclr windows x64 (the failing CI leg):

Sub-condition	Value	Reason
!Is64BitProcess	false	It's x64
SlowRuntimeTimeoutModifier != 1	false	See trace below
!IsNetCore	false	It's .NET Core

Result: true && (false \|\| false \|\| false) → false — test is NOT skipped, timeout persists.

SlowRuntimeTimeoutModifier trace for Checked runtime on x64:

if(IsReleaseRuntime)// false — it's Checkedreturn1;if(IsRiscV64Process)// false — it's x64returnIsDebugRuntime?10:2;elsereturnIsDebugRuntime?5:1;// IsDebugRuntime is false (Checked ≠ Debug) → returns 1

The three runtime modes (Debug, Checked, Release) are mutually exclusive via AssemblyConfigurationEquals. A Checked runtime is neither Debug nor Release, so SlowRuntimeTimeoutModifier falls through to the else branch and returns 1 — the same as Release.

Note: SlowRuntimeTimeoutModifier's own doc comment says "For use as needed on tests that time out when run on a Debug or Checked runtime", but the implementation doesn't account for Checked on non-RISC-V. That appears to be a pre-existing gap in SlowRuntimeTimeoutModifier itself.

Suggested fix — revert to @adamsitnik's first suggestion which correctly handled this:

if(length==2147483591&&(!PlatformDetection.Is64BitProcess||!PlatformDetection.IsReleaseRuntime||!PlatformDetection.IsNetCore))

Or, if SlowRuntimeTimeoutModifier is preferred, fix it first to return > 1 for Checked runtimes (e.g., return IsDebugRuntime ? 5 : IsCheckedRuntime ? 2 : 1;).

(This finding was independently confirmed by both Claude Opus 4.6 and GPT-5.4.)

✅ [ConditionalTheory] without parameters — Correct

Changing from [ConditionalTheory(typeof(PlatformDetection), nameof(PlatformDetection.Is64BitProcess))] to bare [ConditionalTheory] is correct:

• The old attribute skipped all test cases (100, 64K, 127K) on 32-bit, which was unnecessarily restrictive — those small arrays work fine on 32-bit.
• The 32-bit guard is now applied only to the 2 GB case via the in-method check.
• [ConditionalTheory] (vs plain [Theory]) is required for SkipTestException to be reported as a skip rather than a failure, as @danmoseley correctly identified.

✅ Smaller test cases now run on all platforms — Good improvement

The smaller InlineData cases (100, 64_001, 127_000) are no longer gated by #if or 64-bit conditions, expanding test coverage.

Note

This review was generated by Copilot (Claude Opus 4.6), with a parallel review from GPT-5.4.

Generated by Code Review for issue #126006 · ◷

[danmoseley]

@copilot address feedback

[danmoseley]

@copilot it needs to skip on all checked runtimes whatever bitness. See text above

[Copilot]

@copilot it needs to skip on all checked runtimes whatever bitness. See text above

Fixed in ff355fb. SlowRuntimeTimeoutModifier returns 1 for checked builds (it only returns >1 for debug), so it didn't catch the timeout case. Switched to !PlatformDetection.IsReleaseRuntime which correctly skips on checked and debug runtimes of any bitness.

[danmoseley]

/ba-g one issue opened, the others "cffi_backend" already have issue

[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] with platform conditions are replaced with [ConditionalTheory] (no parameters, to allow SkipTestException to be treated as a skip rather than a failure) and a runtime check inside the method body:

[ConditionalTheory][InlineData(100)][InlineData(64_001)][InlineData(127_000)][InlineData(2147483591)]// Array.MaxLengthpublicvoidCanReadArrayOfAnySize(intlength){if(length==2147483591&&(!PlatformDetection.Is64BitProcess||!PlatformDetection.IsReleaseRuntime||!PlatformDetection.IsNetCore)){thrownewSkipTestException("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:

• The process is not 64-bit, or
• The runtime is not a release runtime (!IsReleaseRuntime, which covers both checked and debug coreclr of any bitness), or
• The runtime is not .NET Core (i.e. running on .NET Framework)

!PlatformDetection.IsReleaseRuntime is used instead of SlowRuntimeTimeoutModifier != 1 because SlowRuntimeTimeoutModifier returns 1 for checked (non-release, non-debug) builds, meaning it would not correctly skip the 2 GB test case on checked runtimes.

Using [ConditionalTheory] without parameters (instead of plain [Theory]) ensures that SkipTestException is correctly treated as a skip rather than a test failure.

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...

• FixesSystem.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, recurring CI timeout — CanReadArrayOfAnySize with the 2 GB Array.MaxLength case takes 14+ minutes on the checked coreclr windows x64 Release leg, killing the Helix work item. The original #if RELEASE && NET compile-time guard was ineffective because it checks the library build configuration (always Release), not the runtime configuration. The fix is well-motivated.

Approach: Replacing the compile-time guard with a runtime skip is the right approach, and using [ConditionalTheory] (no parameters) to enable SkipTestException handling is correct. However, the specific runtime condition has a gap that prevents it from fixing the reported issue.

Summary: ❌ Needs Changes. The skip condition uses PlatformDetection.SlowRuntimeTimeoutModifier != 1, but SlowRuntimeTimeoutModifier returns 1 for Checked runtimes on x64 — the exact configuration that's timing out. The 2 GB test case will still run and timeout on checked coreclr x64.

---

Detailed Findings

❌ Skip condition does not fire on checked coreclr x64 — the reported CI leg

The condition at line 71:

if(length==2147483591&&(!PlatformDetection.Is64BitProcess||PlatformDetection.SlowRuntimeTimeoutModifier!=1||!PlatformDetection.IsNetCore))

On checked coreclr windows x64 (the failing CI leg):

Sub-condition	Value	Reason
!Is64BitProcess	false	It's x64
SlowRuntimeTimeoutModifier != 1	false	See trace below
!IsNetCore	false	It's .NET Core

Result: true && (false \|\| false \|\| false) → false — test is NOT skipped, timeout persists.

SlowRuntimeTimeoutModifier trace for Checked runtime on x64:

if(IsReleaseRuntime)// false — it's Checkedreturn1;if(IsRiscV64Process)// false — it's x64returnIsDebugRuntime?10:2;elsereturnIsDebugRuntime?5:1;// IsDebugRuntime is false (Checked ≠ Debug) → returns 1

The three runtime modes (Debug, Checked, Release) are mutually exclusive via AssemblyConfigurationEquals. A Checked runtime is neither Debug nor Release, so SlowRuntimeTimeoutModifier falls through to the else branch and returns 1 — the same as Release.

Note: SlowRuntimeTimeoutModifier's own doc comment says "For use as needed on tests that time out when run on a Debug or Checked runtime", but the implementation doesn't account for Checked on non-RISC-V. That appears to be a pre-existing gap in SlowRuntimeTimeoutModifier itself.

Suggested fix — revert to @adamsitnik's first suggestion which correctly handled this:

if(length==2147483591&&(!PlatformDetection.Is64BitProcess||!PlatformDetection.IsReleaseRuntime||!PlatformDetection.IsNetCore))

Or, if SlowRuntimeTimeoutModifier is preferred, fix it first to return > 1 for Checked runtimes (e.g., return IsDebugRuntime ? 5 : IsCheckedRuntime ? 2 : 1;).

(This finding was independently confirmed by both Claude Opus 4.6 and GPT-5.4.)

✅ [ConditionalTheory] without parameters — Correct

Changing from [ConditionalTheory(typeof(PlatformDetection), nameof(PlatformDetection.Is64BitProcess))] to bare [ConditionalTheory] is correct:

• The old attribute skipped all test cases (100, 64K, 127K) on 32-bit, which was unnecessarily restrictive — those small arrays work fine on 32-bit.
• The 32-bit guard is now applied only to the 2 GB case via the in-method check.
• [ConditionalTheory] (vs plain [Theory]) is required for SkipTestException to be reported as a skip rather than a failure, as @danmoseley correctly identified.

✅ Smaller test cases now run on all platforms — Good improvement

The smaller InlineData cases (100, 64_001, 127_000) are no longer gated by #if or 64-bit conditions, expanding test coverage.

Note

This review was generated by Copilot (Claude Opus 4.6), with a parallel review from GPT-5.4.

Generated by Code Review for issue #126006 · ◷

[danmoseley]

@copilot address feedback

[danmoseley]

@copilot it needs to skip on all checked runtimes whatever bitness. See text above

[Copilot]

@copilot it needs to skip on all checked runtimes whatever bitness. See text above

Fixed in ff355fb. SlowRuntimeTimeoutModifier returns 1 for checked builds (it only returns >1 for debug), so it didn't catch the timeout case. Switched to !PlatformDetection.IsReleaseRuntime which correctly skips on checked and debug runtimes of any bitness.

[danmoseley]

/ba-g one issue opened, the others "cffi_backend" already have issue

[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] with platform conditions are replaced with [ConditionalTheory] (no parameters, to allow SkipTestException to be treated as a skip rather than a failure) and a runtime check inside the method body:

[ConditionalTheory][InlineData(100)][InlineData(64_001)][InlineData(127_000)][InlineData(2147483591)]// Array.MaxLengthpublicvoidCanReadArrayOfAnySize(intlength){if(length==2147483591&&(!PlatformDetection.Is64BitProcess||!PlatformDetection.IsReleaseRuntime||!PlatformDetection.IsNetCore)){thrownewSkipTestException("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:

• The process is not 64-bit, or
• The runtime is not a release runtime (!IsReleaseRuntime, which covers both checked and debug coreclr of any bitness), or
• The runtime is not .NET Core (i.e. running on .NET Framework)

!PlatformDetection.IsReleaseRuntime is used instead of SlowRuntimeTimeoutModifier != 1 because SlowRuntimeTimeoutModifier returns 1 for checked (non-release, non-debug) builds, meaning it would not correctly skip the 2 GB test case on checked runtimes.

Using [ConditionalTheory] without parameters (instead of plain [Theory]) ensures that SkipTestException is correctly treated as a skip rather than a test failure.

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...

• FixesSystem.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, recurring CI timeout — CanReadArrayOfAnySize with the 2 GB Array.MaxLength case takes 14+ minutes on the checked coreclr windows x64 Release leg, killing the Helix work item. The original #if RELEASE && NET compile-time guard was ineffective because it checks the library build configuration (always Release), not the runtime configuration. The fix is well-motivated.

Approach: Replacing the compile-time guard with a runtime skip is the right approach, and using [ConditionalTheory] (no parameters) to enable SkipTestException handling is correct. However, the specific runtime condition has a gap that prevents it from fixing the reported issue.

Summary: ❌ Needs Changes. The skip condition uses PlatformDetection.SlowRuntimeTimeoutModifier != 1, but SlowRuntimeTimeoutModifier returns 1 for Checked runtimes on x64 — the exact configuration that's timing out. The 2 GB test case will still run and timeout on checked coreclr x64.

---

Detailed Findings

❌ Skip condition does not fire on checked coreclr x64 — the reported CI leg

The condition at line 71:

if(length==2147483591&&(!PlatformDetection.Is64BitProcess||PlatformDetection.SlowRuntimeTimeoutModifier!=1||!PlatformDetection.IsNetCore))

On checked coreclr windows x64 (the failing CI leg):

Sub-condition	Value	Reason
!Is64BitProcess	false	It's x64
SlowRuntimeTimeoutModifier != 1	false	See trace below
!IsNetCore	false	It's .NET Core

Result: true && (false \|\| false \|\| false) → false — test is NOT skipped, timeout persists.

SlowRuntimeTimeoutModifier trace for Checked runtime on x64:

if(IsReleaseRuntime)// false — it's Checkedreturn1;if(IsRiscV64Process)// false — it's x64returnIsDebugRuntime?10:2;elsereturnIsDebugRuntime?5:1;// IsDebugRuntime is false (Checked ≠ Debug) → returns 1

The three runtime modes (Debug, Checked, Release) are mutually exclusive via AssemblyConfigurationEquals. A Checked runtime is neither Debug nor Release, so SlowRuntimeTimeoutModifier falls through to the else branch and returns 1 — the same as Release.

Note: SlowRuntimeTimeoutModifier's own doc comment says "For use as needed on tests that time out when run on a Debug or Checked runtime", but the implementation doesn't account for Checked on non-RISC-V. That appears to be a pre-existing gap in SlowRuntimeTimeoutModifier itself.

Suggested fix — revert to @adamsitnik's first suggestion which correctly handled this:

if(length==2147483591&&(!PlatformDetection.Is64BitProcess||!PlatformDetection.IsReleaseRuntime||!PlatformDetection.IsNetCore))

Or, if SlowRuntimeTimeoutModifier is preferred, fix it first to return > 1 for Checked runtimes (e.g., return IsDebugRuntime ? 5 : IsCheckedRuntime ? 2 : 1;).

(This finding was independently confirmed by both Claude Opus 4.6 and GPT-5.4.)

✅ [ConditionalTheory] without parameters — Correct

Changing from [ConditionalTheory(typeof(PlatformDetection), nameof(PlatformDetection.Is64BitProcess))] to bare [ConditionalTheory] is correct:

• The old attribute skipped all test cases (100, 64K, 127K) on 32-bit, which was unnecessarily restrictive — those small arrays work fine on 32-bit.
• The 32-bit guard is now applied only to the 2 GB case via the in-method check.
• [ConditionalTheory] (vs plain [Theory]) is required for SkipTestException to be reported as a skip rather than a failure, as @danmoseley correctly identified.

✅ Smaller test cases now run on all platforms — Good improvement

The smaller InlineData cases (100, 64_001, 127_000) are no longer gated by #if or 64-bit conditions, expanding test coverage.

Note

This review was generated by Copilot (Claude Opus 4.6), with a parallel review from GPT-5.4.

Generated by Code Review for issue #126006 · ◷

[danmoseley]

@copilot address feedback

[danmoseley]

@copilot it needs to skip on all checked runtimes whatever bitness. See text above

[Copilot]

@copilot it needs to skip on all checked runtimes whatever bitness. See text above

Fixed in ff355fb. SlowRuntimeTimeoutModifier returns 1 for checked builds (it only returns >1 for debug), so it didn't catch the timeout case. Switched to !PlatformDetection.IsReleaseRuntime which correctly skips on checked and debug runtimes of any bitness.

[danmoseley]

/ba-g one issue opened, the others "cffi_backend" already have issue

[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] with platform conditions are replaced with [ConditionalTheory] (no parameters, to allow SkipTestException to be treated as a skip rather than a failure) and a runtime check inside the method body:

[ConditionalTheory][InlineData(100)][InlineData(64_001)][InlineData(127_000)][InlineData(2147483591)]// Array.MaxLengthpublicvoidCanReadArrayOfAnySize(intlength){if(length==2147483591&&(!PlatformDetection.Is64BitProcess||!PlatformDetection.IsReleaseRuntime||!PlatformDetection.IsNetCore)){thrownewSkipTestException("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:

• The process is not 64-bit, or
• The runtime is not a release runtime (!IsReleaseRuntime, which covers both checked and debug coreclr of any bitness), or
• The runtime is not .NET Core (i.e. running on .NET Framework)

!PlatformDetection.IsReleaseRuntime is used instead of SlowRuntimeTimeoutModifier != 1 because SlowRuntimeTimeoutModifier returns 1 for checked (non-release, non-debug) builds, meaning it would not correctly skip the 2 GB test case on checked runtimes.

Using [ConditionalTheory] without parameters (instead of plain [Theory]) ensures that SkipTestException is correctly treated as a skip rather than a test failure.

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...

• FixesSystem.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, recurring CI timeout — CanReadArrayOfAnySize with the 2 GB Array.MaxLength case takes 14+ minutes on the checked coreclr windows x64 Release leg, killing the Helix work item. The original #if RELEASE && NET compile-time guard was ineffective because it checks the library build configuration (always Release), not the runtime configuration. The fix is well-motivated.

Approach: Replacing the compile-time guard with a runtime skip is the right approach, and using [ConditionalTheory] (no parameters) to enable SkipTestException handling is correct. However, the specific runtime condition has a gap that prevents it from fixing the reported issue.

Summary: ❌ Needs Changes. The skip condition uses PlatformDetection.SlowRuntimeTimeoutModifier != 1, but SlowRuntimeTimeoutModifier returns 1 for Checked runtimes on x64 — the exact configuration that's timing out. The 2 GB test case will still run and timeout on checked coreclr x64.

---

Detailed Findings

❌ Skip condition does not fire on checked coreclr x64 — the reported CI leg

The condition at line 71:

if(length==2147483591&&(!PlatformDetection.Is64BitProcess||PlatformDetection.SlowRuntimeTimeoutModifier!=1||!PlatformDetection.IsNetCore))

On checked coreclr windows x64 (the failing CI leg):

Sub-condition	Value	Reason
!Is64BitProcess	false	It's x64
SlowRuntimeTimeoutModifier != 1	false	See trace below
!IsNetCore	false	It's .NET Core

Result: true && (false \|\| false \|\| false) → false — test is NOT skipped, timeout persists.

SlowRuntimeTimeoutModifier trace for Checked runtime on x64:

if(IsReleaseRuntime)// false — it's Checkedreturn1;if(IsRiscV64Process)// false — it's x64returnIsDebugRuntime?10:2;elsereturnIsDebugRuntime?5:1;// IsDebugRuntime is false (Checked ≠ Debug) → returns 1

The three runtime modes (Debug, Checked, Release) are mutually exclusive via AssemblyConfigurationEquals. A Checked runtime is neither Debug nor Release, so SlowRuntimeTimeoutModifier falls through to the else branch and returns 1 — the same as Release.

Note: SlowRuntimeTimeoutModifier's own doc comment says "For use as needed on tests that time out when run on a Debug or Checked runtime", but the implementation doesn't account for Checked on non-RISC-V. That appears to be a pre-existing gap in SlowRuntimeTimeoutModifier itself.

Suggested fix — revert to @adamsitnik's first suggestion which correctly handled this:

if(length==2147483591&&(!PlatformDetection.Is64BitProcess||!PlatformDetection.IsReleaseRuntime||!PlatformDetection.IsNetCore))

Or, if SlowRuntimeTimeoutModifier is preferred, fix it first to return > 1 for Checked runtimes (e.g., return IsDebugRuntime ? 5 : IsCheckedRuntime ? 2 : 1;).

(This finding was independently confirmed by both Claude Opus 4.6 and GPT-5.4.)

✅ [ConditionalTheory] without parameters — Correct

Changing from [ConditionalTheory(typeof(PlatformDetection), nameof(PlatformDetection.Is64BitProcess))] to bare [ConditionalTheory] is correct:

• The old attribute skipped all test cases (100, 64K, 127K) on 32-bit, which was unnecessarily restrictive — those small arrays work fine on 32-bit.
• The 32-bit guard is now applied only to the 2 GB case via the in-method check.
• [ConditionalTheory] (vs plain [Theory]) is required for SkipTestException to be reported as a skip rather than a failure, as @danmoseley correctly identified.

✅ Smaller test cases now run on all platforms — Good improvement

The smaller InlineData cases (100, 64_001, 127_000) are no longer gated by #if or 64-bit conditions, expanding test coverage.

Note

This review was generated by Copilot (Claude Opus 4.6), with a parallel review from GPT-5.4.

Generated by Code Review for issue #126006 · ◷

[danmoseley]

@copilot address feedback

[danmoseley]

@copilot it needs to skip on all checked runtimes whatever bitness. See text above

[Copilot]

@copilot it needs to skip on all checked runtimes whatever bitness. See text above

Fixed in ff355fb. SlowRuntimeTimeoutModifier returns 1 for checked builds (it only returns >1 for debug), so it didn't catch the timeout case. Switched to !PlatformDetection.IsReleaseRuntime which correctly skips on checked and debug runtimes of any bitness.

[danmoseley]

/ba-g one issue opened, the others "cffi_backend" already have issue

[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] with platform conditions are replaced with [ConditionalTheory] (no parameters, to allow SkipTestException to be treated as a skip rather than a failure) and a runtime check inside the method body:

[ConditionalTheory][InlineData(100)][InlineData(64_001)][InlineData(127_000)][InlineData(2147483591)]// Array.MaxLengthpublicvoidCanReadArrayOfAnySize(intlength){if(length==2147483591&&(!PlatformDetection.Is64BitProcess||!PlatformDetection.IsReleaseRuntime||!PlatformDetection.IsNetCore)){thrownewSkipTestException("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:

• The process is not 64-bit, or
• The runtime is not a release runtime (!IsReleaseRuntime, which covers both checked and debug coreclr of any bitness), or
• The runtime is not .NET Core (i.e. running on .NET Framework)

!PlatformDetection.IsReleaseRuntime is used instead of SlowRuntimeTimeoutModifier != 1 because SlowRuntimeTimeoutModifier returns 1 for checked (non-release, non-debug) builds, meaning it would not correctly skip the 2 GB test case on checked runtimes.

Using [ConditionalTheory] without parameters (instead of plain [Theory]) ensures that SkipTestException is correctly treated as a skip rather than a test failure.

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...

• FixesSystem.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, recurring CI timeout — CanReadArrayOfAnySize with the 2 GB Array.MaxLength case takes 14+ minutes on the checked coreclr windows x64 Release leg, killing the Helix work item. The original #if RELEASE && NET compile-time guard was ineffective because it checks the library build configuration (always Release), not the runtime configuration. The fix is well-motivated.

Approach: Replacing the compile-time guard with a runtime skip is the right approach, and using [ConditionalTheory] (no parameters) to enable SkipTestException handling is correct. However, the specific runtime condition has a gap that prevents it from fixing the reported issue.

Summary: ❌ Needs Changes. The skip condition uses PlatformDetection.SlowRuntimeTimeoutModifier != 1, but SlowRuntimeTimeoutModifier returns 1 for Checked runtimes on x64 — the exact configuration that's timing out. The 2 GB test case will still run and timeout on checked coreclr x64.

---

Detailed Findings

❌ Skip condition does not fire on checked coreclr x64 — the reported CI leg

The condition at line 71:

if(length==2147483591&&(!PlatformDetection.Is64BitProcess||PlatformDetection.SlowRuntimeTimeoutModifier!=1||!PlatformDetection.IsNetCore))

On checked coreclr windows x64 (the failing CI leg):

Sub-condition	Value	Reason
!Is64BitProcess	false	It's x64
SlowRuntimeTimeoutModifier != 1	false	See trace below
!IsNetCore	false	It's .NET Core

Result: true && (false \|\| false \|\| false) → false — test is NOT skipped, timeout persists.

SlowRuntimeTimeoutModifier trace for Checked runtime on x64:

if(IsReleaseRuntime)// false — it's Checkedreturn1;if(IsRiscV64Process)// false — it's x64returnIsDebugRuntime?10:2;elsereturnIsDebugRuntime?5:1;// IsDebugRuntime is false (Checked ≠ Debug) → returns 1

The three runtime modes (Debug, Checked, Release) are mutually exclusive via AssemblyConfigurationEquals. A Checked runtime is neither Debug nor Release, so SlowRuntimeTimeoutModifier falls through to the else branch and returns 1 — the same as Release.

Note: SlowRuntimeTimeoutModifier's own doc comment says "For use as needed on tests that time out when run on a Debug or Checked runtime", but the implementation doesn't account for Checked on non-RISC-V. That appears to be a pre-existing gap in SlowRuntimeTimeoutModifier itself.

Suggested fix — revert to @adamsitnik's first suggestion which correctly handled this:

if(length==2147483591&&(!PlatformDetection.Is64BitProcess||!PlatformDetection.IsReleaseRuntime||!PlatformDetection.IsNetCore))

Or, if SlowRuntimeTimeoutModifier is preferred, fix it first to return > 1 for Checked runtimes (e.g., return IsDebugRuntime ? 5 : IsCheckedRuntime ? 2 : 1;).

(This finding was independently confirmed by both Claude Opus 4.6 and GPT-5.4.)

✅ [ConditionalTheory] without parameters — Correct

Changing from [ConditionalTheory(typeof(PlatformDetection), nameof(PlatformDetection.Is64BitProcess))] to bare [ConditionalTheory] is correct:

• The old attribute skipped all test cases (100, 64K, 127K) on 32-bit, which was unnecessarily restrictive — those small arrays work fine on 32-bit.
• The 32-bit guard is now applied only to the 2 GB case via the in-method check.
• [ConditionalTheory] (vs plain [Theory]) is required for SkipTestException to be reported as a skip rather than a failure, as @danmoseley correctly identified.

✅ Smaller test cases now run on all platforms — Good improvement

The smaller InlineData cases (100, 64_001, 127_000) are no longer gated by #if or 64-bit conditions, expanding test coverage.

Note

This review was generated by Copilot (Claude Opus 4.6), with a parallel review from GPT-5.4.

Generated by Code Review for issue #126006 · ◷

[danmoseley]

@copilot address feedback

[danmoseley]

@copilot it needs to skip on all checked runtimes whatever bitness. See text above

[Copilot]

@copilot it needs to skip on all checked runtimes whatever bitness. See text above

Fixed in ff355fb. SlowRuntimeTimeoutModifier returns 1 for checked builds (it only returns >1 for debug), so it didn't catch the timeout case. Switched to !PlatformDetection.IsReleaseRuntime which correctly skips on checked and debug runtimes of any bitness.

[danmoseley]

/ba-g one issue opened, the others "cffi_backend" already have issue

[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] with platform conditions are replaced with [ConditionalTheory] (no parameters, to allow SkipTestException to be treated as a skip rather than a failure) and a runtime check inside the method body:

[ConditionalTheory][InlineData(100)][InlineData(64_001)][InlineData(127_000)][InlineData(2147483591)]// Array.MaxLengthpublicvoidCanReadArrayOfAnySize(intlength){if(length==2147483591&&(!PlatformDetection.Is64BitProcess||!PlatformDetection.IsReleaseRuntime||!PlatformDetection.IsNetCore)){thrownewSkipTestException("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:

• The process is not 64-bit, or
• The runtime is not a release runtime (!IsReleaseRuntime, which covers both checked and debug coreclr of any bitness), or
• The runtime is not .NET Core (i.e. running on .NET Framework)

!PlatformDetection.IsReleaseRuntime is used instead of SlowRuntimeTimeoutModifier != 1 because SlowRuntimeTimeoutModifier returns 1 for checked (non-release, non-debug) builds, meaning it would not correctly skip the 2 GB test case on checked runtimes.

Using [ConditionalTheory] without parameters (instead of plain [Theory]) ensures that SkipTestException is correctly treated as a skip rather than a test failure.

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...

• FixesSystem.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, recurring CI timeout — CanReadArrayOfAnySize with the 2 GB Array.MaxLength case takes 14+ minutes on the checked coreclr windows x64 Release leg, killing the Helix work item. The original #if RELEASE && NET compile-time guard was ineffective because it checks the library build configuration (always Release), not the runtime configuration. The fix is well-motivated.

Approach: Replacing the compile-time guard with a runtime skip is the right approach, and using [ConditionalTheory] (no parameters) to enable SkipTestException handling is correct. However, the specific runtime condition has a gap that prevents it from fixing the reported issue.

Summary: ❌ Needs Changes. The skip condition uses PlatformDetection.SlowRuntimeTimeoutModifier != 1, but SlowRuntimeTimeoutModifier returns 1 for Checked runtimes on x64 — the exact configuration that's timing out. The 2 GB test case will still run and timeout on checked coreclr x64.

---

Detailed Findings

❌ Skip condition does not fire on checked coreclr x64 — the reported CI leg

The condition at line 71:

if(length==2147483591&&(!PlatformDetection.Is64BitProcess||PlatformDetection.SlowRuntimeTimeoutModifier!=1||!PlatformDetection.IsNetCore))

On checked coreclr windows x64 (the failing CI leg):

Sub-condition	Value	Reason
!Is64BitProcess	false	It's x64
SlowRuntimeTimeoutModifier != 1	false	See trace below
!IsNetCore	false	It's .NET Core

Result: true && (false \|\| false \|\| false) → false — test is NOT skipped, timeout persists.

SlowRuntimeTimeoutModifier trace for Checked runtime on x64:

if(IsReleaseRuntime)// false — it's Checkedreturn1;if(IsRiscV64Process)// false — it's x64returnIsDebugRuntime?10:2;elsereturnIsDebugRuntime?5:1;// IsDebugRuntime is false (Checked ≠ Debug) → returns 1

The three runtime modes (Debug, Checked, Release) are mutually exclusive via AssemblyConfigurationEquals. A Checked runtime is neither Debug nor Release, so SlowRuntimeTimeoutModifier falls through to the else branch and returns 1 — the same as Release.

Note: SlowRuntimeTimeoutModifier's own doc comment says "For use as needed on tests that time out when run on a Debug or Checked runtime", but the implementation doesn't account for Checked on non-RISC-V. That appears to be a pre-existing gap in SlowRuntimeTimeoutModifier itself.

Suggested fix — revert to @adamsitnik's first suggestion which correctly handled this:

if(length==2147483591&&(!PlatformDetection.Is64BitProcess||!PlatformDetection.IsReleaseRuntime||!PlatformDetection.IsNetCore))

Or, if SlowRuntimeTimeoutModifier is preferred, fix it first to return > 1 for Checked runtimes (e.g., return IsDebugRuntime ? 5 : IsCheckedRuntime ? 2 : 1;).

(This finding was independently confirmed by both Claude Opus 4.6 and GPT-5.4.)

✅ [ConditionalTheory] without parameters — Correct

Changing from [ConditionalTheory(typeof(PlatformDetection), nameof(PlatformDetection.Is64BitProcess))] to bare [ConditionalTheory] is correct:

• The old attribute skipped all test cases (100, 64K, 127K) on 32-bit, which was unnecessarily restrictive — those small arrays work fine on 32-bit.
• The 32-bit guard is now applied only to the 2 GB case via the in-method check.
• [ConditionalTheory] (vs plain [Theory]) is required for SkipTestException to be reported as a skip rather than a failure, as @danmoseley correctly identified.

✅ Smaller test cases now run on all platforms — Good improvement

The smaller InlineData cases (100, 64_001, 127_000) are no longer gated by #if or 64-bit conditions, expanding test coverage.

Note

This review was generated by Copilot (Claude Opus 4.6), with a parallel review from GPT-5.4.

Generated by Code Review for issue #126006 · ◷

[danmoseley]

@copilot address feedback

[danmoseley]

@copilot it needs to skip on all checked runtimes whatever bitness. See text above

[Copilot]

@copilot it needs to skip on all checked runtimes whatever bitness. See text above

Fixed in ff355fb. SlowRuntimeTimeoutModifier returns 1 for checked builds (it only returns >1 for debug), so it didn't catch the timeout case. Switched to !PlatformDetection.IsReleaseRuntime which correctly skips on checked and debug runtimes of any bitness.

[danmoseley]

/ba-g one issue opened, the others "cffi_backend" already have issue

[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] with platform conditions are replaced with [ConditionalTheory] (no parameters, to allow SkipTestException to be treated as a skip rather than a failure) and a runtime check inside the method body:

[ConditionalTheory][InlineData(100)][InlineData(64_001)][InlineData(127_000)][InlineData(2147483591)]// Array.MaxLengthpublicvoidCanReadArrayOfAnySize(intlength){if(length==2147483591&&(!PlatformDetection.Is64BitProcess||!PlatformDetection.IsReleaseRuntime||!PlatformDetection.IsNetCore)){thrownewSkipTestException("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:

• The process is not 64-bit, or
• The runtime is not a release runtime (!IsReleaseRuntime, which covers both checked and debug coreclr of any bitness), or
• The runtime is not .NET Core (i.e. running on .NET Framework)

!PlatformDetection.IsReleaseRuntime is used instead of SlowRuntimeTimeoutModifier != 1 because SlowRuntimeTimeoutModifier returns 1 for checked (non-release, non-debug) builds, meaning it would not correctly skip the 2 GB test case on checked runtimes.

Using [ConditionalTheory] without parameters (instead of plain [Theory]) ensures that SkipTestException is correctly treated as a skip rather than a test failure.

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...

• FixesSystem.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, recurring CI timeout — CanReadArrayOfAnySize with the 2 GB Array.MaxLength case takes 14+ minutes on the checked coreclr windows x64 Release leg, killing the Helix work item. The original #if RELEASE && NET compile-time guard was ineffective because it checks the library build configuration (always Release), not the runtime configuration. The fix is well-motivated.

Approach: Replacing the compile-time guard with a runtime skip is the right approach, and using [ConditionalTheory] (no parameters) to enable SkipTestException handling is correct. However, the specific runtime condition has a gap that prevents it from fixing the reported issue.

Summary: ❌ Needs Changes. The skip condition uses PlatformDetection.SlowRuntimeTimeoutModifier != 1, but SlowRuntimeTimeoutModifier returns 1 for Checked runtimes on x64 — the exact configuration that's timing out. The 2 GB test case will still run and timeout on checked coreclr x64.

---

Detailed Findings

❌ Skip condition does not fire on checked coreclr x64 — the reported CI leg

The condition at line 71:

if(length==2147483591&&(!PlatformDetection.Is64BitProcess||PlatformDetection.SlowRuntimeTimeoutModifier!=1||!PlatformDetection.IsNetCore))

On checked coreclr windows x64 (the failing CI leg):

Sub-condition	Value	Reason
!Is64BitProcess	false	It's x64
SlowRuntimeTimeoutModifier != 1	false	See trace below
!IsNetCore	false	It's .NET Core

Result: true && (false \|\| false \|\| false) → false — test is NOT skipped, timeout persists.

SlowRuntimeTimeoutModifier trace for Checked runtime on x64:

if(IsReleaseRuntime)// false — it's Checkedreturn1;if(IsRiscV64Process)// false — it's x64returnIsDebugRuntime?10:2;elsereturnIsDebugRuntime?5:1;// IsDebugRuntime is false (Checked ≠ Debug) → returns 1

The three runtime modes (Debug, Checked, Release) are mutually exclusive via AssemblyConfigurationEquals. A Checked runtime is neither Debug nor Release, so SlowRuntimeTimeoutModifier falls through to the else branch and returns 1 — the same as Release.

Note: SlowRuntimeTimeoutModifier's own doc comment says "For use as needed on tests that time out when run on a Debug or Checked runtime", but the implementation doesn't account for Checked on non-RISC-V. That appears to be a pre-existing gap in SlowRuntimeTimeoutModifier itself.

Suggested fix — revert to @adamsitnik's first suggestion which correctly handled this:

if(length==2147483591&&(!PlatformDetection.Is64BitProcess||!PlatformDetection.IsReleaseRuntime||!PlatformDetection.IsNetCore))

Or, if SlowRuntimeTimeoutModifier is preferred, fix it first to return > 1 for Checked runtimes (e.g., return IsDebugRuntime ? 5 : IsCheckedRuntime ? 2 : 1;).

(This finding was independently confirmed by both Claude Opus 4.6 and GPT-5.4.)

✅ [ConditionalTheory] without parameters — Correct

Changing from [ConditionalTheory(typeof(PlatformDetection), nameof(PlatformDetection.Is64BitProcess))] to bare [ConditionalTheory] is correct:

• The old attribute skipped all test cases (100, 64K, 127K) on 32-bit, which was unnecessarily restrictive — those small arrays work fine on 32-bit.
• The 32-bit guard is now applied only to the 2 GB case via the in-method check.
• [ConditionalTheory] (vs plain [Theory]) is required for SkipTestException to be reported as a skip rather than a failure, as @danmoseley correctly identified.

✅ Smaller test cases now run on all platforms — Good improvement

The smaller InlineData cases (100, 64_001, 127_000) are no longer gated by #if or 64-bit conditions, expanding test coverage.

Note

This review was generated by Copilot (Claude Opus 4.6), with a parallel review from GPT-5.4.

Generated by Code Review for issue #126006 · ◷

[danmoseley]

@copilot address feedback

[danmoseley]

@copilot it needs to skip on all checked runtimes whatever bitness. See text above

[Copilot]

@copilot it needs to skip on all checked runtimes whatever bitness. See text above

Fixed in ff355fb. SlowRuntimeTimeoutModifier returns 1 for checked builds (it only returns >1 for debug), so it didn't catch the timeout case. Switched to !PlatformDetection.IsReleaseRuntime which correctly skips on checked and debug runtimes of any bitness.

[danmoseley]

/ba-g one issue opened, the others "cffi_backend" already have issue