Skip to content

[pull] master from ruby:master#1174

Merged
pull[bot] merged 9 commits into
turkdevops:masterfrom
ruby:master
Jul 2, 2026
Merged

[pull] master from ruby:master#1174
pull[bot] merged 9 commits into
turkdevops:masterfrom
ruby:master

Conversation

@pull

@pull pull Bot commented Jul 2, 2026

Copy link
Copy Markdown

See Commits and Changes for more details.


Created by pull[bot] (v2.0.0-alpha.4)

Can you help keep this open source service alive? 💖 Please sponsor : )

BurdetteLamar and others added 9 commits July 1, 2026 23:52
Co-authored-by: Jeremy Evans <code@jeremyevans.net>
The "using an implicit hostname" example connects with TCPSocket.new(nil,
port) to a server bound to the IPv4 loopback, then asserts that
local_address.ip_address equals @host ("127.0.0.1"). This is flaky.

A nil hostname resolves to the loopback of both families, and Happy Eyeballs
prefers IPv6, so the connection is not guaranteed to reach the IPv4 test
server. IPv4 and IPv6 can share the same ephemeral port number (v6only), so
under parallel runs (-j20) an unrelated listener on ::1:<same port> can be
reached instead. local_address then comes back as "::1" and the spec fails.

The invariant the example actually wants to check is that local_address
reflects the connection's family, which always matches the peer. Compare
against remote_address.ip_address instead of @host: deterministic in a clean
environment and robust to the cross-family ephemeral-port collision.

Verified: the spec passes normally, and with a forced ::1 listener on the
same port the old `== @host` assertion fails while `== remote` holds.

(Imported from ruby/spec; should be upstreamed there.)

Error:
  TCPSocket#local_address using IPv4 using an implicit hostname the returned
  Addrinfo uses the correct IP address FAILED
  Expected "::1" == "127.0.0.1" to be truthy but was false
  spec/ruby/library/socket/tcpsocket/local_address_spec.rb:68

CI: https://ci.rvm.jp/results/trunk@ruby-sp3/6380323
Log: https://ci.rvm.jp/logfiles/brlog.trunk.20260616-071309

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* Increase timeout of test_port_receive_dnt_with_port_send

Still times out with 90 seconds on Windows CI.

https://github.com/ruby/ruby/actions/runs/28566080915/job/84693945202

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* Keep skipping test_port_receive_dnt_with_port_send on MinGW

The raised timeout is enough for mswin, but the test still times out on
the MinGW runner. Restore the MinGW omit guard while leaving it enabled
on mswin.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

* Keep skipping test_port_receive_dnt_with_port_send on Windows

Even with a 120 second timeout the test still times out on the mswin
runner, so stop running it on Windows entirely. Restore the original
Windows omit guard and the 90 second timeout.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

---------

Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
Fix: ruby/json#976

ruby/json@ea008e82fe

Co-Authored-By: Jean Boussier <byroot@ruby-lang.org>
@pull pull Bot locked and limited conversation to collaborators Jul 2, 2026
@pull pull Bot added the ⤵️ pull label Jul 2, 2026
@pull pull Bot merged commit 7c69f93 into turkdevops:master Jul 2, 2026
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants