Version 0.0.170 unusable without internet access

[maltezellic]

Even using the embedded compiler, version 0.0.170 will still try to access binaries.soliditylang.org. If this fails (e.g. because one is offline), then the Solidity Language Server crashes after the fifth try. There might be overlap with issue #446.

To reproduce, open this solidity file Test.sol:

pragma solidity ^0.8.0;

contract Test {
  
}

with a fresh setup of VSCode 1.85.1 and the solidity extension versions 0.0.170 and 0.0.165, while not having network access. In both cases all settings are default, except that the default compiler has been set to embedded.

Observed behavior:
The Solidity Language Server output shows this with 0.0.165:

[Info  - 1:39:08 PM] Validating using the compiler selected: embedded

Functionality also works, for example pragma is underlined because the SPDX identifiers are missing, and other functionality also appears to work when adding code.

With 0.0.170 instead, this is the output:

[Info  - 1:39:48 PM] Validating using the compiler selected: embedded
/home/user/.vscode/extensions/juanblanco.solidity-0.0.170/node_modules/solc/soljson.js:133
    process["on"]("unhandledRejection", function (reason) { throw reason; });
                                                            ^

Error: getaddrinfo EAI_AGAIN binaries.soliditylang.org
    at GetAddrInfoReqWrap.onlookup [as oncomplete] (node:dns:108:26) {
  errno: -3001,
  code: 'EAI_AGAIN',
  syscall: 'getaddrinfo',
  hostname: 'binaries.soliditylang.org'
}

Node.js v18.15.0
[Info  - 1:39:49 PM] Connection to server got closed. Server will restart.
true
/home/user/.vscode/extensions/juanblanco.solidity-0.0.170/node_modules/solc/soljson.js:133
    process["on"]("unhandledRejection", function (reason) { throw reason; });
                                                            ^

Error: getaddrinfo EAI_AGAIN binaries.soliditylang.org
    at GetAddrInfoReqWrap.onlookup [as oncomplete] (node:dns:108:26) {
  errno: -3001,
  code: 'EAI_AGAIN',
  syscall: 'getaddrinfo',
  hostname: 'binaries.soliditylang.org'
}

Node.js v18.15.0
[Info  - 1:39:50 PM] Connection to server got closed. Server will restart.
true
/home/user/.vscode/extensions/juanblanco.solidity-0.0.170/node_modules/solc/soljson.js:133
    process["on"]("unhandledRejection", function (reason) { throw reason; });
                                                            ^

Error: getaddrinfo EAI_AGAIN binaries.soliditylang.org
    at GetAddrInfoReqWrap.onlookup [as oncomplete] (node:dns:108:26) {
  errno: -3001,
  code: 'EAI_AGAIN',
  syscall: 'getaddrinfo',
  hostname: 'binaries.soliditylang.org'
}

Node.js v18.15.0
[Info  - 1:39:53 PM] Connection to server got closed. Server will restart.
true
/home/user/.vscode/extensions/juanblanco.solidity-0.0.170/node_modules/solc/soljson.js:133
    process["on"]("unhandledRejection", function (reason) { throw reason; });
                                                            ^

Error: getaddrinfo EAI_AGAIN binaries.soliditylang.org
    at GetAddrInfoReqWrap.onlookup [as oncomplete] (node:dns:108:26) {
  errno: -3001,
  code: 'EAI_AGAIN',
  syscall: 'getaddrinfo',
  hostname: 'binaries.soliditylang.org'
}

Node.js v18.15.0
[Info  - 1:39:55 PM] Connection to server got closed. Server will restart.
true
/home/user/.vscode/extensions/juanblanco.solidity-0.0.170/node_modules/solc/soljson.js:133
    process["on"]("unhandledRejection", function (reason) { throw reason; });
                                                            ^

Error: getaddrinfo EAI_AGAIN binaries.soliditylang.org
    at GetAddrInfoReqWrap.onlookup [as oncomplete] (node:dns:108:26) {
  errno: -3001,
  code: 'EAI_AGAIN',
  syscall: 'getaddrinfo',
  hostname: 'binaries.soliditylang.org'
}

Node.js v18.15.0
[Error - 1:39:56 PM] The Solidity Language Server server crashed 5 times in the last 3 minutes. The server will not be restarted. See the output for more information.

Apart from basic syntax highlighting, functionality does not seem to work either.

I noted that in scenarios in which the network access fails only after a timeout, functionality actually does work before the language server crashes. So the network access seems to be unnecessary for functionality also in 0.0.170, so it should likely be considered a bug that the language server crashes in this situation.