v20.0.0 ERR_SOCKET_CONNECTION_TIMEOUT when sending http request to some domains #47822
Comments
|
cc @ShogunPanda - looks like |
bnoordhuis
added
http
|
Yes, it seems to be the case. @lpgera Can you please post here how is that endpoint resolved by your DNS? |
|
These are the outputs from So it seems like there's no IPv6 address and there are two IPv4 addresses resolved, both of which match the TCP handshakes in the Wireshark dump. |
|
I still see these |
|
I'm seeing the same issue attempting to talk to https://api.linode.com/v4/linode/instance - both node-fetch and native fetch are affected. I'm on node v20.2.0 (Intel mac, homebrew) api.linode.com curently resolves as follows as far as I can tell my ipv6 is currently broken (no dancing turtle on https://www.kame.net/) and if edit /etc/hosts to force an IPv4 addresses for api.linode.com the issue goes away |
|
FYI, The fix for this (#47860) was not yet backported to v20, so that is why it's still happening. |
|
For those waiting on a fix: the workaround is to add |
|
This works: and it seems to prevent the A more forward-compatible version (since this bug is fixed in |
|
I am still facing this issue. I am on node v20.2.0. Is there any workaround for getting this to work? |
Oh sorry! Nevermind. the solution by @davidmurdoch works fine. Just including this code on the top fixed my issue. |
where did you add this |
Add it anywhere that will be hit once on start up. |
I added it on the very top of the file. At the very beginning |
|
I encountered this issue in Node I was able to resolve the issue with the workaround provided by @davidmurdoch in #47822 (comment) even though the comment states the problem is fixed in version |
|
It was fixed in 20.3.0 by this PR: https://github.com/nodejs/node/pull/47860/files You should open a new issue if it has regressed. |
|
This should also have been fixed in #51045. Once it gets in 21.x or 20.x please let me know if you have additional problems. |
|
Just stumbled on the issue: It seems like the problem will not appear if my ping is less than 250ms. However what concerns me is that This is how network communication looks in node_20.12.2 / @AWS-SDK / @smythy / 'node:https'.request (ip addresses are hidden for security reasons): As a result, https.request throws AggregateError This is what happens when Results successful network response. |
|
@ZoukEnot Your output above is helpful but slightly confusing. I saw you obfuscated the IP addresses but it seems like the client is connecting to the same IP several times, which should not happen. If that's not the case, can you please use notation like |
Thank you for your time, @ShogunPanda. In the example below I've carefully changed the ip adresses to not expose any sensitive information but to look just as real. Below
DNS response returns exactly one ipv4 address and one ipv6 address. Executing node.js code : Multiple requests to the server happen due to client code receiving Second request is fired at 281ms, indicating that However when The code that triggers https request looks like this (constant values are hardcoded according to the values in debugger): import { request, HttpResponse } from 'https';
const req = request(nodeHttpsOptions, res => {
const response = new HttpResponse({
statusCode: res.statusCode || -1,
reason: res.statusMessage,
headers: res.headers,
body: res,
});
resolve({ response });
});
req.on('error', err => {
// fall here with `ETIMEDOUT`
// then trigger retry in a consuming code
if (['ECONNRESET', 'EPIPE', 'ETIMEDOUT'].includes(err.code)) {
reject(Object.assign(err, { name: 'TimeoutError' }));
} else {
reject(err);
}
});
// does not affect the behavior of the code
req.on("socket", (socket) => {
socket.setKeepAlive(true, 1000);
});Reproduced the behaviour is these node versions:
|
|
I see, I can follow it now.
And in both case post the sequence like you did above? |
Assuming DNS response is the same as in previous example: Below are the results of calling Autoselect timeout 50 ( Autoselect timeout 100 ( Autoselect timeout 150 ( Autoselect timeout 500 (success): |
|
What is confusing me here is that when receiving a timeout the system is somehow retrying it. Second of all, an address is only attempted once. How did you produce the output above? Which tool are you using? |
|
So in which Node 20 versions is this fixed? It was said:
But then
So was there a regression? |
* ci: fix kv-warmer, format files and run tests in CI * chore: pin node version * ci: fix incorrect node path * ci: fix linting and test running * ci: build tiles code * chore: remove cf version metadata as it can't be used from terraform * chore: remove file hash and use file name instead as unique identifier * ci: deploy tiles gha * ci: deploy tiles gha * ci: deploy tiles gha * ci: deploy tiles gha * chore: test push-o-matic * Update tile server file to 20240823.pmtiles * ci: deploy tiles gha * ci: run kv warmer and check if already warm * chore: revert to node 18 because of network problems nodejs/node#47822 * chore: revert back to v1.pmtiles until v4 spec is finalised by protomaps * Update deployment/modules/cloudflare/tiles/workers.tf Fix incorrect environment variable in worker deployment Co-authored-by: bo0tzz <git@bo0tzz.me> * fix: kv-warming deploy on main only --------- Co-authored-by: zackpollard <zackpollard@users.noreply.github.com> Co-authored-by: bo0tzz <git@bo0tzz.me>
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/v2anymore and I always get anERR_SOCKET_CONNECTION_TIMEOUTafter about one second.Reproduction 1:
Reproduction 2:
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?
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
curlfrom every system on which I experience the error and thecurlcommand 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:
The text was updated successfully, but these errors were encountered: