Test failure
System.Net.Sockets.Tests.SocketBlockingModeTransitionTests.ConnectAsync_WithBuffer_Succeeds is failing intermittently on Linux (Ubuntu.2604.Amd64.Open, Alpine.324.Amd64.Open, Alpine.Edge.Amd64.Open, AzureLinux.3.0.ArmArch.Open, Alpine.324.Arm64.Open) in the inner loop across the runtime, runtime-coreclr crossgen2, and runtime-nativeaot-outerloop pipelines.
Error message
Assert.False() Failure
Expected: False
Actual: True
Stack trace:
at System.Net.Sockets.Tests.SocketBlockingModeTransitionTests.ConnectAsync_WithBuffer_Succeeds() in /_/src/libraries/System.Net.Sockets/tests/FunctionalTests/Connect.Unix.cs:line 230
Frequency
11 builds on main plus ~34 PR runs over the past 14 days, exclusively on Linux queues. Ongoing since 2026-08-19.
Analysis
The failing assertion is at Connect.Unix.cs:230:
src/libraries/System.Net.Sockets/tests/FunctionalTests/Connect.Unix.cs
bool completedAsync = client.ConnectAsync(saea);
if (!completedAsync)
{
tcs.SetResult();
}
await tcs.Task;
Assert.Equal(SocketError.Success, saea.SocketError);
Assert.True(client.Blocking);
// On Apple and Android platforms, TFO (connectx/sendto) may complete the connect+send
// in a single syscall, so the socket can end up blocking even on the async path.
// On Linux, async connect always leaves the socket non-blocking when
// buffer > 0 because SendToAsync is pending.
if (!completedAsync || PlatformDetection.IsApplePlatform || PlatformDetection.IsAndroid)
{
Assert.False(IsSocketNonBlocking(client)); // <-- line 230
}
else
{
Assert.True(IsSocketNonBlocking(client));
}On loopback the ConnectAsync(saea) with a send buffer can complete synchronously (completedAsync == false). The test then takes the line-230 branch and asserts the socket has been restored to blocking mode (IsSocketNonBlocking == False). Intermittently the socket is still non-blocking (Actual: True), because a pending async send left over from the connect+send path keeps the descriptor in non-blocking mode.
In other words, the test's assumption that a synchronously-completing ConnectAsync + buffer always restores blocking mode does not hold on Linux loopback: the sync-vs-async classification races with whether the underlying SendToAsync is still pending. This looks like a test-logic race (the !completedAsync branch is not a reliable proxy for "the socket has been restored to blocking mode"), though it may also point at a blocking-mode-restore gap in the sync-completion path.
Suggested fix
Make the blocking-mode assertion tolerant of the sync-completion-with-pending-send case on Linux (e.g. only assert blocking mode when there is genuinely no pending send), or restore blocking mode deterministically before completing the synchronous connect+send path. Until then, filing a Known Build Error so Build Analysis can auto-match this failure.
Sample console log
https://helixr1107v0xdcypoyl9e7f.blob.core.windows.net/dotnet-runtime-refs-heads-main-986da17b21c84d32af/System.Net.Sockets.Tests/1/console.063f084e.log?helixlogtype=result
Known issue error message
Fill the error message using known issues.
{
"ErrorPattern": "System\\.Net\\.Sockets\\.Tests\\.SocketBlockingModeTransitionTests\\.ConnectAsync_WithBuffer_Succeeds",
"BuildRetry": false,
"ExcludeConsoleLog": false
}Known issue validation
Build: 🔎 https://dev.azure.com/dnceng-public/public/_build/results?buildId=1575764
Error message validated: [System\.Net\.Sockets\.Tests\.SocketBlockingModeTransitionTests\.ConnectAsync_WithBuffer_Succeeds]
Result validation: ✅ Known issue matched with the provided build.
Validation performed at: 9/1/2026 1:14:11 PM UTC
Report
Summary
| 24-Hour Hit Count |
7-Day Hit Count |
1-Month Count |
| 23 |
24 |
24 |
Test failure
System.Net.Sockets.Tests.SocketBlockingModeTransitionTests.ConnectAsync_WithBuffer_Succeedsis failing intermittently on Linux (Ubuntu.2604.Amd64.Open,Alpine.324.Amd64.Open,Alpine.Edge.Amd64.Open,AzureLinux.3.0.ArmArch.Open,Alpine.324.Arm64.Open) in the inner loop across theruntime,runtime-coreclr crossgen2, andruntime-nativeaot-outerlooppipelines.Error message
Stack trace:
Frequency
11 builds on main plus ~34 PR runs over the past 14 days, exclusively on Linux queues. Ongoing since 2026-08-19.
Analysis
The failing assertion is at
Connect.Unix.cs:230:src/libraries/System.Net.Sockets/tests/FunctionalTests/Connect.Unix.csOn loopback the
ConnectAsync(saea)with a send buffer can complete synchronously (completedAsync == false). The test then takes the line-230 branch and asserts the socket has been restored to blocking mode (IsSocketNonBlocking == False). Intermittently the socket is still non-blocking (Actual: True), because a pending async send left over from the connect+send path keeps the descriptor in non-blocking mode.In other words, the test's assumption that a synchronously-completing
ConnectAsync+ buffer always restores blocking mode does not hold on Linux loopback: the sync-vs-async classification races with whether the underlyingSendToAsyncis still pending. This looks like a test-logic race (the!completedAsyncbranch is not a reliable proxy for "the socket has been restored to blocking mode"), though it may also point at a blocking-mode-restore gap in the sync-completion path.Suggested fix
Make the blocking-mode assertion tolerant of the sync-completion-with-pending-send case on Linux (e.g. only assert blocking mode when there is genuinely no pending send), or restore blocking mode deterministically before completing the synchronous connect+send path. Until then, filing a Known Build Error so Build Analysis can auto-match this failure.
Sample console log
https://helixr1107v0xdcypoyl9e7f.blob.core.windows.net/dotnet-runtime-refs-heads-main-986da17b21c84d32af/System.Net.Sockets.Tests/1/console.063f084e.log?helixlogtype=result
Known issue error message
Fill the error message using known issues.
{ "ErrorPattern": "System\\.Net\\.Sockets\\.Tests\\.SocketBlockingModeTransitionTests\\.ConnectAsync_WithBuffer_Succeeds", "BuildRetry": false, "ExcludeConsoleLog": false }Known issue validation
Build: 🔎 https://dev.azure.com/dnceng-public/public/_build/results?buildId=1575764
Error message validated:
[System\.Net\.Sockets\.Tests\.SocketBlockingModeTransitionTests\.ConnectAsync_WithBuffer_Succeeds]Result validation: ✅ Known issue matched with the provided build.
Validation performed at: 9/1/2026 1:14:11 PM UTC
Report
Summary