Skip to content

Mark resource-intensive test fixtures as NonParallelizable#712

Open
rhysparry wants to merge 4 commits intomainfrom
rhys/eft-3214/non-parallelizable-heavy-fixtures
Open

Mark resource-intensive test fixtures as NonParallelizable#712
rhysparry wants to merge 4 commits intomainfrom
rhys/eft-3214/non-parallelizable-heavy-fixtures

Conversation

@rhysparry
Copy link
Copy Markdown
Contributor

Summary

The test suite runs with [assembly: Parallelizable(ParallelScope.All)], meaning all fixtures execute concurrently by default. Three fixtures deliberately hold sockets, TLS connections, and threads open for extended periods as part of their test design. When run alongside the full suite they compete for ports and thread-pool threads, causing spurious failures in unrelated tests. This change marks them [NonParallelizable] so they run in isolation.

ProxyFixture

Two of the three tests dispose or pause a real HTTP/SOCKS proxy mid-test and then drive the client through its retry loop (RetryCountLimit = 2, TcpClientConnectTimeout = 5s, PollingRequestQueueTimeout = 10s). Each attempt opens a socket and waits for a connect or read timeout before giving up. The sequence of retries holds file descriptors and OS socket state for ~10–20 seconds per test invocation, a long window during which concurrent tests can exhaust the available ephemeral port range.

BadCertificatesTests

Tests repeatedly establish TLS handshakes with mismatched certificates, causing the SSL layer to reject and retry connections in a tight loop. Several tests set PollingRequestQueueTimeout = TimeSpan.FromSeconds(2000) and use Wait.UntilActionSucceeds loops of up to 20 seconds while the wrong-cert client keeps reconnecting. This produces a sustained burst of TLS negotiation work (certificate parsing, crypto operations) and open sockets that can saturate the thread pool and port space when competing with the rest of the suite.

CancellationViaClientProxyFixture

Tests use EnterKillNewAndExistingConnectionsMode() combined with TryAndConnectForALongTime() to hold the client in a connecting loop, and separately hold an RPC call in-flight (blocking on a sentinel file) before cancelling it. Both patterns keep connections and thread-pool work items live for several seconds by design. The in-flight cancellation test also introduces a deliberate Task.Delay(2s) after cancellation to allow propagation, adding to the window of resource contention.

Test plan

  • Verify existing tests in all three fixtures still pass (no assertions were changed)
  • Confirm CI run shows reduced port/thread contention failures in unrelated fixtures

🤖 Generated with Claude Code

ProxyFixture, BadCertificatesTests, and CancellationViaClientProxyFixture
deliberately hold sockets and TLS connections open for extended periods
while waiting for timeouts or cancellations. Running them concurrently with
the full test suite starves other tests of ports and threads, causing
spurious failures. Isolating them prevents interference without loosening
any assertions.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
@rhysparry rhysparry requested a review from a team as a code owner May 1, 2026 00:51
Copy link
Copy Markdown
Contributor

@gb-8 gb-8 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

✅ Approved!

Curious to see how this impacts overall build time.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants