Flaky: TCPSocketTest failures on Native (linuxX64, mingwX64)
- Dominant language
- Kotlin
- Stars
- 14.5k
- Forks
- 1.3k
- Avg merge
- 2d 13h
- Merged PRs (30d)
- 49
Description
## Description
Multiple `TCPSocketTest` methods fail intermittently on native platforms:
1. `testAcceptErrorOnImmediateSocketClose[linuxX64]` — Expected `IOException`, got `EINVAL` `PosixException`
2. `testAwaitClosedDoesNotDeadLock[mingwX64]` — Race condition: `Failed to connect to InetSocketAddress(127.0.0.1:port)`
## Impact
These failures appear across multiple PRs on Native Linux and Windows CI checks, contributing to "Build All Core" composite failures.
## Affected PRs (sample)
- #5426, #5407, #5402
## Platforms
- Native Linux X64 (linuxX64)
- Native Windows X64 (mingwX64)
## Suggested investigation
- `testAcceptErrorOnImmediateSocketClose`: The test expects `IOException` when a socket is closed immediately, but on Linux native the error comes as a `PosixException` with `EINVAL`. Consider catching both or using a more general assertion.
- `testAwaitClosedDoesNotDeadLock`: Likely a timing issue — the connect attempt happens before the server socket is ready. Consider adding a readiness signal or retry logic.
Contributor guide
Research direction
Start with the TCPSocketTest implementations for testAcceptErrorOnImmediateSocketClose and testAwaitClosedDoesNotDeadLock, then run them on linuxX64 and mingwX64. Check how each platform reports immediate socket closure and how the server becomes ready before connecting. Done means the tests reliably pass on both native targets without masking unrelated failures.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- kotlin
- Domain
- networking, testing-qa
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 52/100