Triage for dotnet/runtime#127422.
Repo filter: All networking issues.
MihuBot version: 5a5ee7.
Ping MihaZupan for any issues.
This is a test triage report generated by AI, aimed at helping the triage team quickly identify past issues/PRs that may be related.
Take any conclusions with a large grain of salt.
Tool logs
dotnet/runtime#127422: Android socket tests failing with IPv6 connectivity issues by github-actions[bot]
Extracted 5 search queries: Android Helix SocketException: Connection refused [::ffff:*] when listening on ::1 (IPv6 loopback), System.Net.Sockets DualModeConnect_DnsEndPointToHost failures on Android (DualMode/IPv6), Dual-mode sockets / IPv6 not configured on Android emulator causing test failures, SocketBlockingModeTransitionTests ConnectAsync_WithBuffer_Succeeds intermittent blocking mode behavior on Android, SocketAsyncEventArgsTest Connect_Parallel_FailsOver preferIPv6 null/Assert.NotNull failure on Android Helix
Found 25 candidate issues
Pull Request #127140 (Apr 20 2026) - "[mobile] Fix SocketBlockingModeTransitionTests on Android"
Summary: Fix merged (Apr 21) that updated the ConnectAsync blocking-mode test to treat Android like Apple platforms. Root cause: Android (like Apple) can complete connect+send in a single syscall (TFO/MSG_FASTOPEN), leaving the fd in blocking mode even when the operation completed asynchronously. The test change added PlatformDetection.IsAndroid to the platform check so the test no longer fails on Android. Relevance: directly addresses the failing test in your report: SocketBlockingModeTransitionTests.ConnectAsync_WithBuffer_Succeeds.
Pull Request #124200 (Feb 9 2026) - "Restore blocking mode after successful ConnectAsync on Unix"
Summary: Library change (merged Mar 17) to restore the underlying socket to blocking mode after a successful ConnectAsync on Unix (unless user explicitly requested non-blocking). Motivated by performance (avoid emulating blocking). There was a lot of discussion about safety (races) and corner cases such as connect+send (TFO) behavior on macOS/Android. Relevance: affects semantics the blocking-mode tests validate; combined with platform-specific TFO quirks can explain test expectations vs. observed behavior on Android.
Pull Request #125717 (Mar 18 2026) - "Fix ConnectAsync_WithBuffer_Succeeds test to include Apple mobile platforms"
Summary: Test change to include Apple mobile platforms in the connectx/TFO blocking-mode check. Relevance: shows prior adjustments were needed per-platform; combined with PR127140/PR124200 indicates this area has required multiple platform-specific fixes and test updates.
Pull Request #125478 (Mar 12 2026) - "[Android] Fix DNS localhost subdomain resolution with IPv6 on Android"
Summary: Fixed DNS-localhost fallback on Android where /etc/hosts maps ::1 to "ip6-localhost" (causing getaddrinfo("localhost", AF_INET6) to fail). The code now retries with "ip6-localhost" (later broadened to all platforms). Tests that depended on localhost IPv6 started passing on Android after this change. Relevance: directly relevant to your "listenOn: ::1 / Connection refused" failures — this PR addresses name-resolution differences that can make IPv6 loopback lookups fail on Android emulators.
Issue #104709 (Jul 11 2024) - "Connection issues in Sockets and Functional networking tests"
Summary: Multiple Android networking tests were failing with NetworkUnreachable / similar errors due to Helix devices lacking internet / host reachability. The issue was ultimately infra-related; internet connectivity was restored and the failures stopped. Relevance: supports the new-issue hypothesis that many Android socket failures can be caused by test infra/environment rather than library regressions.
Issue #122493 (Dec 12 2025) - "SocketException 'Connection reset by peer' causing test failures on android_arm64 and android_x64"
Summary: A cluster of Android failures (connection resets) appeared across many Socket tests on various android jobs. These were intermittent and platform-specific. Relevance: mirrors the "Connection refused" / connectivity class of failures in your report — another example of Android-specific network flakiness in CI.
Issue #50568 (Apr 1 2021) - "System.Net.Sockets.Tests fails on Android"
Summary: Many Socket tests failed on Android historically (permission, SIOCATMARK, canceled sends, unexpected behavior). Several tests were disabled or had ActiveIssue annotations. Relevance: shows Android often has platform-specific behavior or limitations that cause socket tests to fail; useful context when deciding to skip/test-adjust on Android.
Issue #81946 (Feb 10 2023) - "System.Net.Sockets BeginReceiveMessageFromV4BoundToSpecificV6_NotReceived test is failing"
Summary: A DualMode/connectionless test started failing on Android after a change and was eventually disabled. Relevance: dual-mode/IPv4-vs-IPv6 tests have a history of being flaky on Android and sometimes get disabled or require special handling.
Issue #123797 (Jan 30 2026) - "Assert.Equal failure in SocketAsyncEventArgsTest.Connect_Parallel_FailsOver"
Summary: Parallel connect tests failed on tvOS with unexpected non-null remote endpoint values and related timing/connect issues; indicates platform-specific test flakiness in parallel/connection-failover tests. Relevance: your report includes a Connect_Parallel_FailsOver failure (Assert.NotNull): this issue shows similar failures on other non-Android mobile platforms and suggests the problem space spans timing, resolver behavior, and platform differences, not only Android.
Issues #22225 / #21853 (2017) - "DualModeConnectAsync / DualModeConnect" (historical)
Summary: DualModeConnect tests have intermittently timed out or failed across many OSes over the years; most occurrences were attributed to infra or OS/network stack differences and were not always actionable in the runtime. Relevance: historical precedent that DualMode/connect tests are flaky and sensitive to environment; supports treating current Android failures as possibly infra/environmental.
Notes / implications for triage
- There are already recent fixes addressing both (a) blocking-mode semantics (PR124200, PR127140, PR125717) and (b) Android DNS/localhost IPv6 resolution (PR125478). Verify whether the failing runs include those commits. If they are present and failures persist, then infra (network connectivity, emulator IPv6 config) is the likely cause—see #104709 and #122493 for similar infra-driven symptoms.
- The Connect_Parallel_FailsOver / other parallel connect failures have precedent on mobile platforms (timing/race/flaky behavior). If failures are intermittent, consider initial mitigation by marking affected tests with ActiveIssue on Android until infra is stabilized or a deterministic repro is available.
- For SocketBlockingModeTransitionTests, PR127140 should have fixed the specific test you listed; cross-check that the failing log came from a run prior to that PR merging (or from a configuration that didn't pick up the change).
- For IPv6 loopback tests: ensure the Helix Android images have IPv6 loopback reachable and that DNS/local hosts handling matches expectations (PR125478 fixed some name-resolution fallbacks, but the emulator's network stack must still support binding/listening on ::1).
If you want, I can:
- Check whether the failing Helix job run you linked includes the fixes from PR125478 / PR124200 / PR127140, or
- Produce a short checklist of infra checks to run on the Android Helix images (IPv6 enabled, /etc/hosts content, outbound connectivity) to help decide skip vs. fix.
Triage for dotnet/runtime#127422.
Repo filter: All networking issues.
MihuBot version:
5a5ee7.Ping MihaZupan for any issues.
This is a test triage report generated by AI, aimed at helping the triage team quickly identify past issues/PRs that may be related.
Take any conclusions with a large grain of salt.
Tool logs
Pull Request #127140 (Apr 20 2026) - "[mobile] Fix SocketBlockingModeTransitionTests on Android"
Summary: Fix merged (Apr 21) that updated the ConnectAsync blocking-mode test to treat Android like Apple platforms. Root cause: Android (like Apple) can complete connect+send in a single syscall (TFO/MSG_FASTOPEN), leaving the fd in blocking mode even when the operation completed asynchronously. The test change added PlatformDetection.IsAndroid to the platform check so the test no longer fails on Android. Relevance: directly addresses the failing test in your report: SocketBlockingModeTransitionTests.ConnectAsync_WithBuffer_Succeeds.
Pull Request #124200 (Feb 9 2026) - "Restore blocking mode after successful ConnectAsync on Unix"
Summary: Library change (merged Mar 17) to restore the underlying socket to blocking mode after a successful ConnectAsync on Unix (unless user explicitly requested non-blocking). Motivated by performance (avoid emulating blocking). There was a lot of discussion about safety (races) and corner cases such as connect+send (TFO) behavior on macOS/Android. Relevance: affects semantics the blocking-mode tests validate; combined with platform-specific TFO quirks can explain test expectations vs. observed behavior on Android.
Pull Request #125717 (Mar 18 2026) - "Fix ConnectAsync_WithBuffer_Succeeds test to include Apple mobile platforms"
Summary: Test change to include Apple mobile platforms in the connectx/TFO blocking-mode check. Relevance: shows prior adjustments were needed per-platform; combined with PR127140/PR124200 indicates this area has required multiple platform-specific fixes and test updates.
Pull Request #125478 (Mar 12 2026) - "[Android] Fix DNS localhost subdomain resolution with IPv6 on Android"
Summary: Fixed DNS-localhost fallback on Android where /etc/hosts maps ::1 to "ip6-localhost" (causing getaddrinfo("localhost", AF_INET6) to fail). The code now retries with "ip6-localhost" (later broadened to all platforms). Tests that depended on localhost IPv6 started passing on Android after this change. Relevance: directly relevant to your "listenOn: ::1 / Connection refused" failures — this PR addresses name-resolution differences that can make IPv6 loopback lookups fail on Android emulators.
Issue #104709 (Jul 11 2024) - "Connection issues in Sockets and Functional networking tests"
Summary: Multiple Android networking tests were failing with NetworkUnreachable / similar errors due to Helix devices lacking internet / host reachability. The issue was ultimately infra-related; internet connectivity was restored and the failures stopped. Relevance: supports the new-issue hypothesis that many Android socket failures can be caused by test infra/environment rather than library regressions.
Issue #122493 (Dec 12 2025) - "SocketException 'Connection reset by peer' causing test failures on android_arm64 and android_x64"
Summary: A cluster of Android failures (connection resets) appeared across many Socket tests on various android jobs. These were intermittent and platform-specific. Relevance: mirrors the "Connection refused" / connectivity class of failures in your report — another example of Android-specific network flakiness in CI.
Issue #50568 (Apr 1 2021) - "System.Net.Sockets.Tests fails on Android"
Summary: Many Socket tests failed on Android historically (permission, SIOCATMARK, canceled sends, unexpected behavior). Several tests were disabled or had ActiveIssue annotations. Relevance: shows Android often has platform-specific behavior or limitations that cause socket tests to fail; useful context when deciding to skip/test-adjust on Android.
Issue #81946 (Feb 10 2023) - "System.Net.Sockets BeginReceiveMessageFromV4BoundToSpecificV6_NotReceived test is failing"
Summary: A DualMode/connectionless test started failing on Android after a change and was eventually disabled. Relevance: dual-mode/IPv4-vs-IPv6 tests have a history of being flaky on Android and sometimes get disabled or require special handling.
Issue #123797 (Jan 30 2026) - "Assert.Equal failure in SocketAsyncEventArgsTest.Connect_Parallel_FailsOver"
Summary: Parallel connect tests failed on tvOS with unexpected non-null remote endpoint values and related timing/connect issues; indicates platform-specific test flakiness in parallel/connection-failover tests. Relevance: your report includes a Connect_Parallel_FailsOver failure (Assert.NotNull): this issue shows similar failures on other non-Android mobile platforms and suggests the problem space spans timing, resolver behavior, and platform differences, not only Android.
Issues #22225 / #21853 (2017) - "DualModeConnectAsync / DualModeConnect" (historical)
Summary: DualModeConnect tests have intermittently timed out or failed across many OSes over the years; most occurrences were attributed to infra or OS/network stack differences and were not always actionable in the runtime. Relevance: historical precedent that DualMode/connect tests are flaky and sensitive to environment; supports treating current Android failures as possibly infra/environmental.
Notes / implications for triage
If you want, I can: