Fix test runner silent failure on dual-stack IPv4/IPv6 systems

[Copilot]

Motivation

On systems where localhost resolves to both IPv6 (::1) and IPv4 (127.0.0.1), test runs hang indefinitely without error indication. The Ruby client connects to whichever address the system resolver returns first (typically IPv6), while the VS Code extension may only listen on IPv4. Connection failures were silently swallowed by a bare rescue block.

Implementation

Ruby LSP Reporter (lib/ruby_lsp/test_reporters/lsp_reporter.rb):

• Connect to 127.0.0.1 explicitly instead of localhost hostname
• Log connection errors to stderr before falling back to StringIO

VS Code Extension (vscode/src/streamingRunner.ts):

• Listen on 127.0.0.1 explicitly instead of localhost hostname

Both client and server now use IPv4 explicitly, eliminating address family mismatches. The fix is minimal—changing hostname strings rather than implementing complex dual-stack logic.

Automated Tests

Added two tests to test/test_reporters/lsp_reporter_test.rb:

• test_socket_connects_to_ipv4_explicitly - Verifies successful IPv4 connection
• test_socket_uses_ipv4_address_not_localhost - Verifies AF_INET address family

Manual Tests

On a system with both IPv4 and IPv6 support:

1. Run any test through the Test Explorer
2. Verify test results appear (previously would hang indefinitely)
3. To test error logging, stop the extension and run tests—stderr will show connection error

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Test runner fails silently when IPv6 is supported</issue_title>
<issue_description>### Description

I found that LSPReporter's creation of the TCPSocket only attempts to connect to IPv6. On my machine, localhost resolves to both.

DNS resolution details

> dscacheutil -q host -a name localhost
name: localhost
ipv6_address: ::1

name: localhost
ip_address: 127.0.0.1

The Ruby TCPSocket client should optimally attempt to connect to both addresses returned by resolution. I'm not sure why it doesn't.

But the other cause of this is the VSCode extension is only listening on IPv4. This seems to be true of other VSCode extensions, so this might be configuration that VSCode sets.

In my listening ports, most other processes listen on both IPv6 and IPv4 localhost. Only VSCode seems to fail in this respect.

lsof output

> lsof -iTCP -sTCP:LISTEN -P
COMMAND     PID   USER   FD   TYPE             DEVICE SIZE/OFF NODE NAME
memcached  1617 robind   26u  IPv6 0x416e0cf960b506a6      0t0  TCP localhost:11211 (LISTEN)
memcached  1617 robind   27u  IPv4 0xbe64df4d8fdeb937      0t0  TCP localhost:11211 (LISTEN)
redis-ser  1624 robind    6u  IPv4 0xafc32bd063db8f53      0t0  TCP localhost:6379 (LISTEN)
redis-ser  1624 robind    7u  IPv6 0xbb97f3cfabb65bca      0t0  TCP localhost:6379 (LISTEN)
postgres   1633 robind    7u  IPv6 0x9d3f57f413cf9e1c      0t0  TCP localhost:5432 (LISTEN)
postgres   1633 robind    8u  IPv4 0x2cdded71d7a286a2      0t0  TCP localhost:5432 (LISTEN)
mongod    29865 robind    9u  IPv4 0x5ac4b24364c26c6e      0t0  TCP localhost:27017 (LISTEN)
mongod    29865 robind   10u  IPv6 0xe670461630259d9f      0t0  TCP localhost:27017 (LISTEN)
Code\x20H 61560 robind   57u  IPv4 0x3c2ce31b9e4f2072      0t0  TCP localhost:49642 (LISTEN)
Code\x20H 61560 robind  102u  IPv4 0x2deb28c5c60d4feb      0t0  TCP localhost:56812 (LISTEN)
Code\x20H 65192 robind   66u  IPv4 0x7b605db7e44b6576      0t0  TCP localhost:56597 (LISTEN)
Code\x20H 65192 robind   71u  IPv4 0x2cfd373aa98f7e5b      0t0  TCP localhost:40868 (LISTEN)
Cursor    97186 robind   55u  IPv4 0xdcb9f4394bb6b830      0t0  TCP localhost:27967 (LISTEN)
Cursor    97186 robind   94u  IPv4 0x68a1c36c0bec2080      0t0  TCP localhost:58848 (LISTEN)
Cursor    97187 robind   47u  IPv4 0x67b20e79b8eeb201      0t0  TCP localhost:58706 (LISTEN)
Cursor    97187 robind   69u  IPv4 0x7ebd32d392f7bd2d      0t0  TCP localhost:59743 (LISTEN)
Cursor    97188 robind   55u  IPv4 0x568a9269f1414376      0t0  TCP localhost:36218 (LISTEN)
Cursor    97188 robind   89u  IPv4 0x9a613b38375ece36      0t0  TCP localhost:58853 (LISTEN)

Next, the connection failure is swallowed by the rescue block which instantiates a StringIO. This causes a silent failure without logging any hint as to the issue, because writes to the StringIO go nowhere.

Finally, the extension never times out on a test run. Telling the extension to restart the LSP server doesn't end the waiting state either. The extension host must be restarted to be able to start another test run. This seems like it would also affect other failures of the test runner, for example if it crashes without sending the "finish" message.

Ruby LSP Information

VS Code Version

(Cursor Version: 2.2.20)

VSCode 1.105.1

MacOS 15.7.2

Also reproduced in VSCode 1.107.0

Ruby LSP Extension Version

0.9.32

Ruby LSP Server Version

0.26.4

Ruby LSP Add-ons

• Ruby LSP RSpec (0.26.4)
• Ruby LSP Rails (0.4.8)
• RuboCop (1.81.7)

Ruby Version

3.3.1

Ruby Version Manager

rbenv

Installed Extensions

Click to expand

• claude-code (2.0.62)
• continue (1.2.11)
• debugpy (2025.14.1)
• multi-cursor-case-preserve (1.0.5)
• op-vscode (1.0.5)
• prettier-vscode (11.0.2)
• python (2025.6.1)
• rainbow-csv (3.3.0)
• ruby-lsp (0.9.32)
• test-adapter-converter (0.2.1)
• vscode-alternate-alternate-file (0.3.2)
• vscode-dash (2.4.0)
• vscode-eslint (3.0.16)
• vscode-github-actions (0.28.0)
• vscode-markdownlint (0.60.0)
• vscode-pull-request-github (0.120.2)
• vscode-rdbg (0.2.2)
• vscode-typescript-next (6.0.20250801)
• vscode-yaml (1.19.1)

Ruby LSP Settings

Click to expand

Workspace

{}

User

{
  "enabledFeatures": {
    "codeActions": true,
    "diagnostics": true,
    "documentHighlights": true,
    "documentLink": true,
    "documentSymbols": true,
    "foldingRanges": true,
    "formatting": true,
    "hover": true,
 ...

</details>



<!-- START COPILOT CODING AGENT SUFFIX -->

- Fixes Shopify/ruby-lsp#3868

<!-- START COPILOT CODING AGENT TIPS -->
---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more [Copilot coding agent tips](https://gh.io/copilot-coding-agent-tips) in the docs.