test-net-listen-ipv6only is flaky due to IPv4 port collision #64172

Test

test/parallel/test-net-listen-ipv6only.js

Platform

Environment-independent root cause; observed on macOS (arm64) but can occur on any platform under high test parallelism.

Console output

Observed once during a full python3 tools/test.py run (5521 passing, this test failing). The test passes 10/10 when run in isolation, which is the typical signature of a port-collision flake.

What is the problem?

The test verifies that ipv6Only: true disables dual-stack support. It listens on :: with an ephemeral port (port: 0) and then connects to the same port over IPv4 (0.0.0.0), expecting ECONNREFUSED — i.e. it assumes the IPv4 side of that port is free:

server.listen({ host: '::', port: 0, ipv6Only: true }, common.mustCall(() => {
  const { port } = server.address();
  const socket = net.connect({ host: '0.0.0.0', port });
  socket.on('connect', common.mustNotCall());            // <- fires under collision
  socket.on('error', common.mustCall((err) => {
    assert.strictEqual(err.code, 'ECONNREFUSED');
    server.close();
  }));
}));

The IPv4 side of the chosen ephemeral port is never reserved. Under heavy parallel
execution another test can occupy that same IPv4 port, so the connection succeeds
instead of being refused and common.mustNotCall() on 'connect' fires (or the
ECONNREFUSED assertion fails).

This is the same port-collision flake that previously affected the sibling cluster
variants — see #25813 / #29679, fixed in #26298 ("eliminate port collision"),
#32381 and #32398, which moved the ipv6Only: true cases to test/sequential/
with a static port. The plain (non-cluster) test never received that treatment.

Fix

Move the test to test/sequential/ and use a fixed common.PORT, so it does not run
concurrently with other tests competing for the same IPv4 port. PR to follow.