Flaky under parallel make: OAuthTransportTest#test_https_proxy_refused_without_p_use_ssl_support does live DNS inside a 1s bound

[jeremy]

What happens

ruby/test/basecamp/oauth_transport_test.rb:839 —
OAuthTransportTest#test_https_proxy_refused_without_p_use_ssl_support — was
observed failing during a parallel make run while the #669/#674 build-hygiene
wave was being proven (2026-08-12, macOS, several concurrent agent workspaces on
one machine). It passes on a quiet machine and it passed on every serial run
since. Filing it rather than fixing it, because it is out of scope for the PR
that hit it and it should not be lost.

I have not reproduced it deterministically. What follows is a mechanism read of
the source, which is the actionable part.

Why it is timing-dependent

The test asserts the fetcher refuses an https:// proxy when the bundled
net-http lacks Net::HTTP.new's eighth p_use_ssl parameter:

error = assert_raises(Basecamp::Oauth::OauthError) do
  Basecamp::Oauth::Fetcher.stream_http(:get, "https://old-net-http.test/token", timeout: 1)
end
assert_equal "validation", error.type

That OauthError is raised at ruby/lib/basecamp/oauth/fetcher.rb:371. Reaching
it requires getting past line 363 first:

proxy_uri = Timeout.timeout(timeout, Net::OpenTimeout) { uri.find_proxy }

URI::Generic#find_proxy resolves the target hostname — IPSocket.getaddress —
to evaluate its loopback rule. The fetcher's own comment above that line says so
and is deliberate about it ("a blocking DNS call that must sit inside the
advertised bound like every other network step"). So the test performs a live
DNS lookup for old-net-http.test inside a 1-second bound, before the
assertion's subject is ever evaluated.

.test is RFC 6761 reserved, so this is normally a fast NXDOMAIN — but it is
still a real query to whatever resolver the machine has. Blow the second and the
Timeout fires instead, surfacing as Faraday::TimeoutError rather than
Basecamp::Oauth::OauthError, and assert_raises fails. Under make -j the
same machine is running npm, uv, bundler, Gradle and Go concurrently, which is
exactly when a resolver round-trip stops being free.

That predicts a specific failure signature. Worth confirming against the real
failure output before acting:

Expected Basecamp::Oauth::OauthError, got #<Faraday::TimeoutError>

If the observed failure was a different error or a different assertion, this
analysis is wrong and the finding still stands on the observation.

Notes for whoever picks it up

• The neighbouring test at oauth_transport_test.rb:800 already stubs
  IPSocket.getaddress (there, to simulate a stall). This test does not, so it
  is the only one in the file whose pass/fail depends on the machine's resolver.
• The timeout: 1 is doing double duty: the test's subject is a validation
  refusal that needs no timeout at all, but the value also bounds a DNS call the
  test does not care about.
• Directions, not a prescription — which is right depends on what the test is
  meant to pin: stub the resolution the way its neighbour does; raise the bound;
  or reorder so the capability check precedes proxy resolution (that last one
  changes shipped behaviour and would need its own argument).
• ruby/test is not parallelized (no parallelize_me!), so this is not
  intra-suite interference. The concurrency is make -j across toolchains,
  competing for the machine — not for Ruby's process.

Scope

Split off from the PR closing #669 and #674. That PR closes #674 against its
Gradle half only (serializing the Gradle-backed check-targets); this is the
other thing make -j surfaced, and it is unrelated to Gradle.

[jeremy]

Second observation in this file, different mechanism — recording it here rather than filing separately, because the useful signal is that OAuthTransportTest has a class problem under load, not one bad test.

Observed on #721's CI (Ruby 4.0), on a branch that touches only scripts/check-wrapper-drift/*.go. A Go-only change cannot affect Ruby OAuth transport, so this is environmental:

1) Failure:
OAuthTransportTest#test_proxy_connect_drip_is_bounded_by_the_deadline [test/basecamp/oauth_transport_test.rb:970]:
the proxy never saw the client cut the CONNECT drip — the whole-phase connect bound did not fire

1414 runs, 30584 assertions, 1 failures, 0 errors, 0 skips

Why this one is more interesting than a routine flake

That test was already hardened by #708, and the comment above the failing assertion says so explicitly:

Assert the MECHANISM, not wall clock (#708) [...] The pop timeout is a WAIT bound, not a timing assertion — as generous as the hang guard, so a loaded runner cannot fail it spuriously (#708's whole class).

The failing line is assert cut.pop(timeout: 15). So the deflake reasoning was that 15 seconds is far outside any plausible scheduling delay — and a loaded runner blew through it anyway. #708 did the right thing by moving from wall-clock to mechanism assertions; what this shows is that the wait bound guarding the mechanism is still a timing assumption, just a generous one.

Distinct from this issue's original finding

• This issue as filed: test_https_proxy_refused_without_p_use_ssl_support (:840) does a live DNS lookup for old-net-http.test inside a 1-second bound, surfacing Faraday::TimeoutError before the validation error it asserts on. Fix is to remove the DNS dependency.
• This observation: test_proxy_connect_drip_is_bounded_by_the_deadline (:970) waits up to 15s for a real proxy socket to observe a client-side cut. Fix is presumably to decouple the assertion from a live socket handshake, or accept a much larger bound.

Different tests, different causes, one shared property: both depend on real network machinery completing within a fixed wall-clock window on a shared runner. Whoever picks this up should probably scope the fix to that property across the file rather than to the two tests individually — otherwise this recurs with a third test.

Both were observed under contention (parallel make locally for the first, a busy CI runner with several concurrent workflows for the second), which is consistent with load being the trigger rather than either test being wrong in isolation.

[jeremy]

Correcting my own comment above: I said these were two mechanisms. They are one, and it isn't timing. PR #734 has the proof.

stream_http calls URI#find_proxy inside the deadline. find_proxy calls IPSocket.getaddress. Every proxy test in this file targets a .test name, which RFC 6761 makes permanently unresolvable — so a real NXDOMAIN round trip sits inside a 0.5–1s budget. Under load the resolver is the whole failure, in both tests I described as unrelated.

The sweep found four affected tests, not two.

That also answers the question I raised about why #708's hardening didn't hold. I'd read it as "the wait bound is still a timing assumption, just a generous one." Wrong: the 15-second bound was never the problem. With a slow resolver the proxy never receives a CONNECT at all, and an empty queue is indistinguishable from a late one at any wait length. Widening it further would never have helped, and #708's move from wall-clock to mechanism assertions was correct — it just couldn't see past a dependency neither test declared.

The fix stubs getaddress behind a shared with_proxy_env helper and widens no bound. The red proof reproduces the proxy never saw the client cut the CONNECT drip character-for-character from a single injected cause, which is the strongest available evidence that one cause produces both reported symptoms.

Two things #734 is honest about not proving, worth carrying forward:

• It is not proven that resolver latency caused the specific CI failures recorded here — no DNS timing was captured on those runs. The injected cause reproduces both messages exactly and is the most economical explanation, but if the real cause was different, this doesn't address it. What is proven is that these tests no longer touch the resolver at all.
• The sub-second assert_operator seconds, :<, TIMEOUT bounds elsewhere in the file were deliberately left alone. They look like the same shape but aren't: there, the margin between correct (~10ms) and broken is the deadline, so widening deletes the discrimination rather than protecting it, and no mechanism assertion is available to replace it. None has been observed failing.

My "different tests, different causes" framing was wrong. The instinct to scope the fix to a shared property rather than to individual tests was right, and it's what turned up the other two.