Test runner fails silently when IPv6 is supported

[RobinDaugherty]

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,
    "inlayHint": true,
    "onTypeFormatting": true,
    "selectionRanges": true,
    "semanticHighlighting": true,
    "completion": true,
    "codeLens": true,
    "definition": true,
    "workspaceSymbol": true,
    "signatureHelp": true,
    "typeHierarchy": true
  },
  "featuresConfiguration": {},
  "addonSettings": {},
  "rubyVersionManager": {
    "identifier": "rbenv"
  },
  "customRubyCommand": "",
  "formatter": "rubocop_internal",
  "linters": null,
  "bundleGemfile": "",
  "testTimeout": 30,
  "branch": "",
  "pullDiagnosticsOn": "both",
  "useBundlerCompose": false,
  "bypassTypechecker": false,
  "rubyExecutablePath": "",
  "indexing": {},
  "erbSupport": true,
  "featureFlags": {},
  "sigOpacityLevel": "1"
}

Reproduction steps

1. Have a Mac with both IPv4 and IPv6 networking
2. In the Test Explorer, run any test
3. In the Test Results tab, see rspec run and complete

Expected: test results are indicated in Test Explorer

Actual: Test Explorer item stays in "waiting" state forever, and never displays the results.

[egiurleo]

Hi, @RobinDaugherty! Thanks for raising this issue. As more of the industry moves to prioritizing IPv6 over v4, we're definitely going to need to address it. We're wrapping up some more urgent work, so we won't have time for this for ~ a couple months. If you have capacity or interest, feel free to open a PR and we'd love to review it. Otherwise, we'll revisit in the new year!