Skip CooperativeBlockingCanCreateThreadsFaster on Debug runtimes by Copilot · Pull Request #131834 · dotnet/runtime

Copilot · 2026-08-04T22:04:02Z

ThreadPoolTests.CooperativeBlockingCanCreateThreadsFaster is timing-sensitive and has been failing intermittently in CI. Every observed failure was in a Debug configuration, where the runtime is slow enough that the test's timing assumptions no longer hold — consistent with the historical investigation in #66765, which attributed failures to timeouts under concurrent load.

Changes

Added IsThreadingAndRemoteExecutorSupportedAndNotDebugRuntime to ThreadPoolTests, combining the existing condition with !PlatformDetection.IsDebugRuntime.
Switched the ConditionalFact on CooperativeBlockingCanCreateThreadsFaster to use it, so the test still runs in Release/Checked and is skipped on Debug.

// Timing-sensitive tests can be too flaky on a Debug runtime, which is much slowerpublicstaticboolIsThreadingAndRemoteExecutorSupportedAndNotDebugRuntime=>
IsThreadingAndRemoteExecutorSupported &&!PlatformDetection.IsDebugRuntime;

Test-only change; no product code is affected.

FixesThreadPoolTests.CooperativeBlockingCanCreateThreadsFaster failed on 10.0 on Windows #129976

Copilot

Copilot wasn't able to review any files in this pull request.

azure-pipelines · 2026-08-04T22:04:18Z

Azure Pipelines: 16 pipeline(s) were filtered out due to trigger conditions. There may be pipelines that require an authorized user to comment /azp run to run.

Co-authored-by: VSadov <8218165+VSadov@users.noreply.github.com>

Copilot

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.

Suppressed comments (1)

src/libraries/System.Threading.ThreadPool/tests/ThreadPoolTests.cs:1506

PlatformDetection already provides SlowRuntimeTimeoutModifier specifically for tests that time out on Debug/Checked runtimes (see PlatformDetection.SlowRuntimeTimeoutModifier). Skipping the test entirely on Debug reduces coverage and may mask debug-only issues; consider instead scaling the WaitOne timeout by SlowRuntimeTimeoutModifier (or otherwise using that helper) so the test can still run on slower runtimes, unless there’s a strong reason to avoid lengthening Debug CI runs.

 // Timing-sensitive tests can be too flaky on a Debug runtime, which is much slower
public static bool IsThreadingAndRemoteExecutorSupportedAndNotDebugRuntime =>
IsThreadingAndRemoteExecutorSupported && !PlatformDetection.IsDebugRuntime;

VSadov · 2026-08-04T22:13:35Z

@eduardo-vp - a test only change blocking a test on Debug corelib.

I do not think the PR will fail, since the failure is fairly rare. We can merge and see if it still reproduces.

dotnet-policy-service · 2026-08-04T22:26:19Z

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

azure-pipelines · 2026-08-04T22:41:51Z

Azure Pipelines: Successfully started running 3 pipeline(s). 13 pipeline(s) were filtered out due to trigger conditions. There may be pipelines that require an authorized user to comment /azp run to run.

JulieLeeMSFT

LGTM.

VSadov · 2026-08-06T19:47:03Z

/ba-g this is a test-only change, failures are in completely unrelated tests

Copilot · 2026-08-04T22:04:02Z

ThreadPoolTests.CooperativeBlockingCanCreateThreadsFaster is timing-sensitive and has been failing intermittently in CI. Every observed failure was in a Debug configuration, where the runtime is slow enough that the test's timing assumptions no longer hold — consistent with the historical investigation in #66765, which attributed failures to timeouts under concurrent load.

Changes

Added IsThreadingAndRemoteExecutorSupportedAndNotDebugRuntime to ThreadPoolTests, combining the existing condition with !PlatformDetection.IsDebugRuntime.
Switched the ConditionalFact on CooperativeBlockingCanCreateThreadsFaster to use it, so the test still runs in Release/Checked and is skipped on Debug.

// Timing-sensitive tests can be too flaky on a Debug runtime, which is much slowerpublicstaticboolIsThreadingAndRemoteExecutorSupportedAndNotDebugRuntime=>
IsThreadingAndRemoteExecutorSupported &&!PlatformDetection.IsDebugRuntime;

Test-only change; no product code is affected.

FixesThreadPoolTests.CooperativeBlockingCanCreateThreadsFaster failed on 10.0 on Windows #129976

Copilot

Copilot wasn't able to review any files in this pull request.

azure-pipelines · 2026-08-04T22:04:18Z

Azure Pipelines: 16 pipeline(s) were filtered out due to trigger conditions. There may be pipelines that require an authorized user to comment /azp run to run.

Co-authored-by: VSadov <8218165+VSadov@users.noreply.github.com>

Copilot

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.

Suppressed comments (1)

src/libraries/System.Threading.ThreadPool/tests/ThreadPoolTests.cs:1506

PlatformDetection already provides SlowRuntimeTimeoutModifier specifically for tests that time out on Debug/Checked runtimes (see PlatformDetection.SlowRuntimeTimeoutModifier). Skipping the test entirely on Debug reduces coverage and may mask debug-only issues; consider instead scaling the WaitOne timeout by SlowRuntimeTimeoutModifier (or otherwise using that helper) so the test can still run on slower runtimes, unless there’s a strong reason to avoid lengthening Debug CI runs.

 // Timing-sensitive tests can be too flaky on a Debug runtime, which is much slower
public static bool IsThreadingAndRemoteExecutorSupportedAndNotDebugRuntime =>
IsThreadingAndRemoteExecutorSupported && !PlatformDetection.IsDebugRuntime;

VSadov · 2026-08-04T22:13:35Z

@eduardo-vp - a test only change blocking a test on Debug corelib.

I do not think the PR will fail, since the failure is fairly rare. We can merge and see if it still reproduces.

dotnet-policy-service · 2026-08-04T22:26:19Z

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

azure-pipelines · 2026-08-04T22:41:51Z

Azure Pipelines: Successfully started running 3 pipeline(s). 13 pipeline(s) were filtered out due to trigger conditions. There may be pipelines that require an authorized user to comment /azp run to run.

JulieLeeMSFT

LGTM.

VSadov · 2026-08-06T19:47:03Z

/ba-g this is a test-only change, failures are in completely unrelated tests

Copilot · 2026-08-04T22:04:02Z

ThreadPoolTests.CooperativeBlockingCanCreateThreadsFaster is timing-sensitive and has been failing intermittently in CI. Every observed failure was in a Debug configuration, where the runtime is slow enough that the test's timing assumptions no longer hold — consistent with the historical investigation in #66765, which attributed failures to timeouts under concurrent load.

Changes

Added IsThreadingAndRemoteExecutorSupportedAndNotDebugRuntime to ThreadPoolTests, combining the existing condition with !PlatformDetection.IsDebugRuntime.
Switched the ConditionalFact on CooperativeBlockingCanCreateThreadsFaster to use it, so the test still runs in Release/Checked and is skipped on Debug.

// Timing-sensitive tests can be too flaky on a Debug runtime, which is much slowerpublicstaticboolIsThreadingAndRemoteExecutorSupportedAndNotDebugRuntime=>
IsThreadingAndRemoteExecutorSupported &&!PlatformDetection.IsDebugRuntime;

Test-only change; no product code is affected.

FixesThreadPoolTests.CooperativeBlockingCanCreateThreadsFaster failed on 10.0 on Windows #129976

Copilot

Copilot wasn't able to review any files in this pull request.

azure-pipelines · 2026-08-04T22:04:18Z

Azure Pipelines: 16 pipeline(s) were filtered out due to trigger conditions. There may be pipelines that require an authorized user to comment /azp run to run.

Co-authored-by: VSadov <8218165+VSadov@users.noreply.github.com>

Copilot

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.

Suppressed comments (1)

src/libraries/System.Threading.ThreadPool/tests/ThreadPoolTests.cs:1506

PlatformDetection already provides SlowRuntimeTimeoutModifier specifically for tests that time out on Debug/Checked runtimes (see PlatformDetection.SlowRuntimeTimeoutModifier). Skipping the test entirely on Debug reduces coverage and may mask debug-only issues; consider instead scaling the WaitOne timeout by SlowRuntimeTimeoutModifier (or otherwise using that helper) so the test can still run on slower runtimes, unless there’s a strong reason to avoid lengthening Debug CI runs.

 // Timing-sensitive tests can be too flaky on a Debug runtime, which is much slower
public static bool IsThreadingAndRemoteExecutorSupportedAndNotDebugRuntime =>
IsThreadingAndRemoteExecutorSupported && !PlatformDetection.IsDebugRuntime;

VSadov · 2026-08-04T22:13:35Z

@eduardo-vp - a test only change blocking a test on Debug corelib.

I do not think the PR will fail, since the failure is fairly rare. We can merge and see if it still reproduces.

dotnet-policy-service · 2026-08-04T22:26:19Z

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

azure-pipelines · 2026-08-04T22:41:51Z

Azure Pipelines: Successfully started running 3 pipeline(s). 13 pipeline(s) were filtered out due to trigger conditions. There may be pipelines that require an authorized user to comment /azp run to run.

JulieLeeMSFT

LGTM.

VSadov · 2026-08-06T19:47:03Z

/ba-g this is a test-only change, failures are in completely unrelated tests

Copilot · 2026-08-04T22:04:02Z

ThreadPoolTests.CooperativeBlockingCanCreateThreadsFaster is timing-sensitive and has been failing intermittently in CI. Every observed failure was in a Debug configuration, where the runtime is slow enough that the test's timing assumptions no longer hold — consistent with the historical investigation in #66765, which attributed failures to timeouts under concurrent load.

Changes

Added IsThreadingAndRemoteExecutorSupportedAndNotDebugRuntime to ThreadPoolTests, combining the existing condition with !PlatformDetection.IsDebugRuntime.
Switched the ConditionalFact on CooperativeBlockingCanCreateThreadsFaster to use it, so the test still runs in Release/Checked and is skipped on Debug.

// Timing-sensitive tests can be too flaky on a Debug runtime, which is much slowerpublicstaticboolIsThreadingAndRemoteExecutorSupportedAndNotDebugRuntime=>
IsThreadingAndRemoteExecutorSupported &&!PlatformDetection.IsDebugRuntime;

Test-only change; no product code is affected.

FixesThreadPoolTests.CooperativeBlockingCanCreateThreadsFaster failed on 10.0 on Windows #129976

Copilot

Copilot wasn't able to review any files in this pull request.

azure-pipelines · 2026-08-04T22:04:18Z

Azure Pipelines: 16 pipeline(s) were filtered out due to trigger conditions. There may be pipelines that require an authorized user to comment /azp run to run.

Co-authored-by: VSadov <8218165+VSadov@users.noreply.github.com>

Copilot

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.

Suppressed comments (1)

src/libraries/System.Threading.ThreadPool/tests/ThreadPoolTests.cs:1506

PlatformDetection already provides SlowRuntimeTimeoutModifier specifically for tests that time out on Debug/Checked runtimes (see PlatformDetection.SlowRuntimeTimeoutModifier). Skipping the test entirely on Debug reduces coverage and may mask debug-only issues; consider instead scaling the WaitOne timeout by SlowRuntimeTimeoutModifier (or otherwise using that helper) so the test can still run on slower runtimes, unless there’s a strong reason to avoid lengthening Debug CI runs.

 // Timing-sensitive tests can be too flaky on a Debug runtime, which is much slower
public static bool IsThreadingAndRemoteExecutorSupportedAndNotDebugRuntime =>
IsThreadingAndRemoteExecutorSupported && !PlatformDetection.IsDebugRuntime;

VSadov · 2026-08-04T22:13:35Z

@eduardo-vp - a test only change blocking a test on Debug corelib.

I do not think the PR will fail, since the failure is fairly rare. We can merge and see if it still reproduces.

dotnet-policy-service · 2026-08-04T22:26:19Z

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

azure-pipelines · 2026-08-04T22:41:51Z

Azure Pipelines: Successfully started running 3 pipeline(s). 13 pipeline(s) were filtered out due to trigger conditions. There may be pipelines that require an authorized user to comment /azp run to run.

JulieLeeMSFT

LGTM.

VSadov · 2026-08-06T19:47:03Z

/ba-g this is a test-only change, failures are in completely unrelated tests

Copilot · 2026-08-04T22:04:02Z

ThreadPoolTests.CooperativeBlockingCanCreateThreadsFaster is timing-sensitive and has been failing intermittently in CI. Every observed failure was in a Debug configuration, where the runtime is slow enough that the test's timing assumptions no longer hold — consistent with the historical investigation in #66765, which attributed failures to timeouts under concurrent load.

Changes

Added IsThreadingAndRemoteExecutorSupportedAndNotDebugRuntime to ThreadPoolTests, combining the existing condition with !PlatformDetection.IsDebugRuntime.
Switched the ConditionalFact on CooperativeBlockingCanCreateThreadsFaster to use it, so the test still runs in Release/Checked and is skipped on Debug.

// Timing-sensitive tests can be too flaky on a Debug runtime, which is much slowerpublicstaticboolIsThreadingAndRemoteExecutorSupportedAndNotDebugRuntime=>
IsThreadingAndRemoteExecutorSupported &&!PlatformDetection.IsDebugRuntime;

Test-only change; no product code is affected.

FixesThreadPoolTests.CooperativeBlockingCanCreateThreadsFaster failed on 10.0 on Windows #129976

Copilot

Copilot wasn't able to review any files in this pull request.

azure-pipelines · 2026-08-04T22:04:18Z

Azure Pipelines: 16 pipeline(s) were filtered out due to trigger conditions. There may be pipelines that require an authorized user to comment /azp run to run.

Co-authored-by: VSadov <8218165+VSadov@users.noreply.github.com>

Copilot

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.

Suppressed comments (1)

src/libraries/System.Threading.ThreadPool/tests/ThreadPoolTests.cs:1506

PlatformDetection already provides SlowRuntimeTimeoutModifier specifically for tests that time out on Debug/Checked runtimes (see PlatformDetection.SlowRuntimeTimeoutModifier). Skipping the test entirely on Debug reduces coverage and may mask debug-only issues; consider instead scaling the WaitOne timeout by SlowRuntimeTimeoutModifier (or otherwise using that helper) so the test can still run on slower runtimes, unless there’s a strong reason to avoid lengthening Debug CI runs.

 // Timing-sensitive tests can be too flaky on a Debug runtime, which is much slower
public static bool IsThreadingAndRemoteExecutorSupportedAndNotDebugRuntime =>
IsThreadingAndRemoteExecutorSupported && !PlatformDetection.IsDebugRuntime;

VSadov · 2026-08-04T22:13:35Z

@eduardo-vp - a test only change blocking a test on Debug corelib.

I do not think the PR will fail, since the failure is fairly rare. We can merge and see if it still reproduces.

dotnet-policy-service · 2026-08-04T22:26:19Z

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

azure-pipelines · 2026-08-04T22:41:51Z

Azure Pipelines: Successfully started running 3 pipeline(s). 13 pipeline(s) were filtered out due to trigger conditions. There may be pipelines that require an authorized user to comment /azp run to run.

JulieLeeMSFT

LGTM.

VSadov · 2026-08-06T19:47:03Z

/ba-g this is a test-only change, failures are in completely unrelated tests

Copilot · 2026-08-04T22:04:02Z

ThreadPoolTests.CooperativeBlockingCanCreateThreadsFaster is timing-sensitive and has been failing intermittently in CI. Every observed failure was in a Debug configuration, where the runtime is slow enough that the test's timing assumptions no longer hold — consistent with the historical investigation in #66765, which attributed failures to timeouts under concurrent load.

Changes

Added IsThreadingAndRemoteExecutorSupportedAndNotDebugRuntime to ThreadPoolTests, combining the existing condition with !PlatformDetection.IsDebugRuntime.
Switched the ConditionalFact on CooperativeBlockingCanCreateThreadsFaster to use it, so the test still runs in Release/Checked and is skipped on Debug.

// Timing-sensitive tests can be too flaky on a Debug runtime, which is much slowerpublicstaticboolIsThreadingAndRemoteExecutorSupportedAndNotDebugRuntime=>
IsThreadingAndRemoteExecutorSupported &&!PlatformDetection.IsDebugRuntime;

Test-only change; no product code is affected.

FixesThreadPoolTests.CooperativeBlockingCanCreateThreadsFaster failed on 10.0 on Windows #129976

Copilot

Copilot wasn't able to review any files in this pull request.

azure-pipelines · 2026-08-04T22:04:18Z

Azure Pipelines: 16 pipeline(s) were filtered out due to trigger conditions. There may be pipelines that require an authorized user to comment /azp run to run.

Co-authored-by: VSadov <8218165+VSadov@users.noreply.github.com>

Copilot

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.

Suppressed comments (1)

src/libraries/System.Threading.ThreadPool/tests/ThreadPoolTests.cs:1506

PlatformDetection already provides SlowRuntimeTimeoutModifier specifically for tests that time out on Debug/Checked runtimes (see PlatformDetection.SlowRuntimeTimeoutModifier). Skipping the test entirely on Debug reduces coverage and may mask debug-only issues; consider instead scaling the WaitOne timeout by SlowRuntimeTimeoutModifier (or otherwise using that helper) so the test can still run on slower runtimes, unless there’s a strong reason to avoid lengthening Debug CI runs.

 // Timing-sensitive tests can be too flaky on a Debug runtime, which is much slower
public static bool IsThreadingAndRemoteExecutorSupportedAndNotDebugRuntime =>
IsThreadingAndRemoteExecutorSupported && !PlatformDetection.IsDebugRuntime;

VSadov · 2026-08-04T22:13:35Z

@eduardo-vp - a test only change blocking a test on Debug corelib.

I do not think the PR will fail, since the failure is fairly rare. We can merge and see if it still reproduces.

dotnet-policy-service · 2026-08-04T22:26:19Z

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

azure-pipelines · 2026-08-04T22:41:51Z

Azure Pipelines: Successfully started running 3 pipeline(s). 13 pipeline(s) were filtered out due to trigger conditions. There may be pipelines that require an authorized user to comment /azp run to run.

JulieLeeMSFT

LGTM.

VSadov · 2026-08-06T19:47:03Z

/ba-g this is a test-only change, failures are in completely unrelated tests

Copilot · 2026-08-04T22:04:02Z

ThreadPoolTests.CooperativeBlockingCanCreateThreadsFaster is timing-sensitive and has been failing intermittently in CI. Every observed failure was in a Debug configuration, where the runtime is slow enough that the test's timing assumptions no longer hold — consistent with the historical investigation in #66765, which attributed failures to timeouts under concurrent load.

Changes

Added IsThreadingAndRemoteExecutorSupportedAndNotDebugRuntime to ThreadPoolTests, combining the existing condition with !PlatformDetection.IsDebugRuntime.
Switched the ConditionalFact on CooperativeBlockingCanCreateThreadsFaster to use it, so the test still runs in Release/Checked and is skipped on Debug.

// Timing-sensitive tests can be too flaky on a Debug runtime, which is much slowerpublicstaticboolIsThreadingAndRemoteExecutorSupportedAndNotDebugRuntime=>
IsThreadingAndRemoteExecutorSupported &&!PlatformDetection.IsDebugRuntime;

Test-only change; no product code is affected.

FixesThreadPoolTests.CooperativeBlockingCanCreateThreadsFaster failed on 10.0 on Windows #129976

Copilot

Copilot wasn't able to review any files in this pull request.

azure-pipelines · 2026-08-04T22:04:18Z

Azure Pipelines: 16 pipeline(s) were filtered out due to trigger conditions. There may be pipelines that require an authorized user to comment /azp run to run.

Co-authored-by: VSadov <8218165+VSadov@users.noreply.github.com>

Copilot

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.

Suppressed comments (1)

src/libraries/System.Threading.ThreadPool/tests/ThreadPoolTests.cs:1506

PlatformDetection already provides SlowRuntimeTimeoutModifier specifically for tests that time out on Debug/Checked runtimes (see PlatformDetection.SlowRuntimeTimeoutModifier). Skipping the test entirely on Debug reduces coverage and may mask debug-only issues; consider instead scaling the WaitOne timeout by SlowRuntimeTimeoutModifier (or otherwise using that helper) so the test can still run on slower runtimes, unless there’s a strong reason to avoid lengthening Debug CI runs.

 // Timing-sensitive tests can be too flaky on a Debug runtime, which is much slower
public static bool IsThreadingAndRemoteExecutorSupportedAndNotDebugRuntime =>
IsThreadingAndRemoteExecutorSupported && !PlatformDetection.IsDebugRuntime;

VSadov · 2026-08-04T22:13:35Z

@eduardo-vp - a test only change blocking a test on Debug corelib.

I do not think the PR will fail, since the failure is fairly rare. We can merge and see if it still reproduces.

dotnet-policy-service · 2026-08-04T22:26:19Z

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

azure-pipelines · 2026-08-04T22:41:51Z

Azure Pipelines: Successfully started running 3 pipeline(s). 13 pipeline(s) were filtered out due to trigger conditions. There may be pipelines that require an authorized user to comment /azp run to run.

JulieLeeMSFT

LGTM.

VSadov · 2026-08-06T19:47:03Z

/ba-g this is a test-only change, failures are in completely unrelated tests

Copilot · 2026-08-04T22:04:02Z

ThreadPoolTests.CooperativeBlockingCanCreateThreadsFaster is timing-sensitive and has been failing intermittently in CI. Every observed failure was in a Debug configuration, where the runtime is slow enough that the test's timing assumptions no longer hold — consistent with the historical investigation in #66765, which attributed failures to timeouts under concurrent load.

Changes

Added IsThreadingAndRemoteExecutorSupportedAndNotDebugRuntime to ThreadPoolTests, combining the existing condition with !PlatformDetection.IsDebugRuntime.
Switched the ConditionalFact on CooperativeBlockingCanCreateThreadsFaster to use it, so the test still runs in Release/Checked and is skipped on Debug.

// Timing-sensitive tests can be too flaky on a Debug runtime, which is much slowerpublicstaticboolIsThreadingAndRemoteExecutorSupportedAndNotDebugRuntime=>
IsThreadingAndRemoteExecutorSupported &&!PlatformDetection.IsDebugRuntime;

Test-only change; no product code is affected.

FixesThreadPoolTests.CooperativeBlockingCanCreateThreadsFaster failed on 10.0 on Windows #129976

Copilot

Copilot wasn't able to review any files in this pull request.

azure-pipelines · 2026-08-04T22:04:18Z

Azure Pipelines: 16 pipeline(s) were filtered out due to trigger conditions. There may be pipelines that require an authorized user to comment /azp run to run.

Co-authored-by: VSadov <8218165+VSadov@users.noreply.github.com>

Copilot

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.

Suppressed comments (1)

src/libraries/System.Threading.ThreadPool/tests/ThreadPoolTests.cs:1506

PlatformDetection already provides SlowRuntimeTimeoutModifier specifically for tests that time out on Debug/Checked runtimes (see PlatformDetection.SlowRuntimeTimeoutModifier). Skipping the test entirely on Debug reduces coverage and may mask debug-only issues; consider instead scaling the WaitOne timeout by SlowRuntimeTimeoutModifier (or otherwise using that helper) so the test can still run on slower runtimes, unless there’s a strong reason to avoid lengthening Debug CI runs.

 // Timing-sensitive tests can be too flaky on a Debug runtime, which is much slower
public static bool IsThreadingAndRemoteExecutorSupportedAndNotDebugRuntime =>
IsThreadingAndRemoteExecutorSupported && !PlatformDetection.IsDebugRuntime;

VSadov · 2026-08-04T22:13:35Z

@eduardo-vp - a test only change blocking a test on Debug corelib.

I do not think the PR will fail, since the failure is fairly rare. We can merge and see if it still reproduces.

dotnet-policy-service · 2026-08-04T22:26:19Z

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

azure-pipelines · 2026-08-04T22:41:51Z

Azure Pipelines: Successfully started running 3 pipeline(s). 13 pipeline(s) were filtered out due to trigger conditions. There may be pipelines that require an authorized user to comment /azp run to run.

JulieLeeMSFT

LGTM.

VSadov · 2026-08-06T19:47:03Z

/ba-g this is a test-only change, failures are in completely unrelated tests

Initial plan
6ac6035

CopilotAI assigned Copilot and VSadov Aug 4, 2026

CopilotAI review requested due to automatic review settings August 4, 2026 22:04

CopilotAI reviewed Aug 4, 2026
View reviewed changes

Copilotstarted work on behalf of VSadov August 4, 2026 22:05 View session

CopilotAI linked an issue Aug 4, 2026 that may be closed by this pull request
ThreadPoolTests.CooperativeBlockingCanCreateThreadsFaster failed on 10.0 on Windows #129976
Closed

Disable CooperativeBlockingCanCreateThreadsFaster on Debug runtime
db5d361
Co-authored-by: VSadov <8218165+VSadov@users.noreply.github.com>

CopilotAI review requested due to automatic review settings August 4, 2026 22:07

CopilotAI changed the title ~~[WIP] Fix ThreadPoolTests.CooperativeBlockingCanCreateThreadsFaster failure on Windows~~Skip CooperativeBlockingCanCreateThreadsFaster on Debug runtimesAug 4, 2026

Copilotstarted reviewing on behalf of VSadov August 4, 2026 22:08 View session

Copilotfinished work on behalf of VSadov August 4, 2026 22:08

CopilotAI requested a review from VSadov August 4, 2026 22:08

CopilotAI reviewed Aug 4, 2026
View reviewed changes

VSadov requested a review from eduardo-vp August 4, 2026 22:12

github-actionsBot added the area-System.Threading label Aug 4, 2026

VSadov marked this pull request as ready for review August 4, 2026 22:41

eduardo-vp approved these changes Aug 4, 2026
View reviewed changes

VSadov enabled auto-merge (squash) August 4, 2026 23:37

This was referenced Aug 5, 2026
Android WebSocket failure #121518
Open
Assertion failure in ConnectAsync_WithBuffer_Succeeds on Android/MacCatalyst/tvOS (Mono/CoreCLR/NativeAOT) #125825
Open

JulieLeeMSFT approved these changes Aug 5, 2026
View reviewed changes

VSadov merged commit 276c0bf into mainAug 6, 2026
86 of 88 checks passed

VSadov deleted the copilot/fix-cooperative-blocking-tests branch August 6, 2026 19:47

dotnet-maestroBot mentioned this pull request Aug 7, 2026
[main] Source code updates from dotnet/runtime dotnet/dotnet#8185
Merged

dotnet-milestone-botBot added this to the 11.0-rc1 milestone Aug 7, 2026