Adopting dns result order changes with Node v18 update

[deepak1556]

The change comes in via Electron 25 update #188268 which bumps our Node.js version from v16 -> v18. Node.js no longer sorts the DNS lookup results from the OS. This might break situations where one might expect to connect to a ipv4 localhost but OS resolves localhost to ipv6 address, which would result in ECONNREFUSED. Node.js has provided a couple of different settings to control this behavior

i) Process wide cli flag --dns-result-order=ipv4first|verbatim
ii) Per thread API in the dns module, dns.setDefaultResultOder
iii) Socket option autoSelectFamily to use happy eyeballs algorithm that will attempt to connect with ipv4 and ipv6 addresses until a connection is established.

I have adopted (i) in src/vs/server/node/extensionHostConnection.ts and src/vs/workbench/services/extensions/electron-sandbox/localProcessExtensionHost.ts to provide the old behavior in extension host spawned from both client and server. @alexdima let me know if we want to plan an action item to remove this workaround in future releases of VSCode.

This issue is created for callsites that are binding to 127.0.0.1 to verify if they are impacted by the Node.js change when connecting to these servers,

• cli/src/commands/tunnels.rs @connor4312
• cli/src/tunnels/control_server.rs @connor4312
• extensions/github-authentication/src/node/authServer.ts @TylerLeonhardt
• extensions/microsoft-authentication/src/node/authServer.ts @TylerLeonhardt
• extensions/vscode-test-resolver/src/extension.ts @aeschli
• src/vs/base/node/ports.ts @alexdima
• src/vs/platform/tunnel/node/tunnelService.ts @alexr00
• src/vs/platform/webview/common/webviewPortMapping.ts @mjbvz

[TylerLeonhardt]

The auth extensions spin up servers that get open in the user's web browser. I verified the flows still work post-electron update.

[aeschli]

@deepak1556 Is there some guidelines what to watch out for? My understanding is that when you listen to localhost, then you might now get end up with server on a v6 address (::1).
If you listen to 127.0.0.1 you get a server on the v4 address, as before.
That's why I think no changes are needed to https://github.com/microsoft/vscode/blob/main/extensions/vscode-test-resolver/src/extension.ts
Please let me know if there's more to it.

[deepak1556]

My understanding is that when you listen to localhost, then you might now get end up with server on a v6 address (::1).
If you listen to 127.0.0.1 you get a server on the v4 address, as before.

Yup this is correct

What I would like to be verified is there are two servers listening on 127.0.0.1 in

vscode/extensions/vscode-test-resolver/src/extension.ts

Line 311 in ccb95fd

proxyServer.listen(0, '127.0.0.1', () => {

and

vscode/extensions/vscode-test-resolver/src/extension.ts

Line 560 in ccb95fd

proxyServer.listen(localPort, '127.0.0.1', () => {

. I am not sure if the client also connects on 127.0.0.1 or localhost and ensure that the connection is not broken with the Node v18 update.

[aeschli]

I'm quite sure this still works as the test resolver is used for run our remote integration tests.