Description
Version
v20.0.0
Platform
macOS 13.3.1, Linux linux 5.15.84-v8+ # 1613 SMP PREEMPT Thu Jan 5 12:03:08 GMT 2023 aarch64 GNU/Linux
Subsystem
http
What steps will reproduce the bug?
After switching to v20.0.0, I cannot send requests to https://api.airvisual.com/v2 anymore and I always get an ERR_SOCKET_CONNECTION_TIMEOUT after about one second.
Reproduction 1:
await fetch('https://api.airvisual.com/v2')Reproduction 2:
require('https').get('https://api.airvisual.com/v2', (resp) => {
let data = ''
resp.on('data', (chunk) => data += chunk)
resp.on('end', () => console.log(data))
})How often does it reproduce? Is there a required condition?
The issue is only present on v20.0.0, previous versions work fine.
What is the expected behavior? Why is that the expected behavior?
The API should respond with the following JSON body: {"status":"fail","data":{"message":"incorrect_api_key"}}.
What do you see instead?
> await fetch('https://api.airvisual.com/v2')
Uncaught TypeError: fetch failed
at Object.fetch (node:internal/deps/undici/undici:11457:11)
at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
at async REPL18:1:33 {
cause: Error [ERR_SOCKET_CONNECTION_TIMEOUT]: Socket connection timeout
at new NodeError (node:internal/errors:399:5)
at internalConnectMultiple (node:net:1098:20)
at Timeout.internalConnectMultipleTimeout (node:net:1637:3)
at listOnTimeout (node:internal/timers:575:11)
at process.processTimers (node:internal/timers:514:7) {
code: 'ERR_SOCKET_CONNECTION_TIMEOUT'
}
}Additional information
Tried a couple of other domains, such as example.com, google.com, cloudflare.com and the requests work fine.
Switching back to v19.8.1 makes the requests to api.airvisual.com work again, so the error seems to be node 20 specific.
I tried talking to the HTTP api instead of using HTTPS and I receive the same error in node.
I tried running curl from every system on which I experience the error and the curl command always succeeded.
Tried looking into the network traffic with Wireshark and what I can see is that the node process starts connecting to both resolved IPv4 addresses, and then the connection is immediately closed by the client:
