Since a couple of days I often face timeout when I run my NodeJS command lines that interacts with the IC on mainnet but I’m not sure if it’s something on my hand (NodeJS version, Macos, network etc.) or if something on the IC side.
Has anyone else being to face recently timeout in his/her scripts?
Sound like a network issue. I was in the office today, stayed there after work to developed few stuffs and had no issue. Just went home and timeout happened again, so restarted my router, let’s see.
Let me know the results please! I have had the same issue for a couple weeks and I just use my VPN with no issues.
Yesterday evening after restart it seemed more stable. However at some point I noticed again a new timeout. I’ll keep monitoring and let you know.
Alright so same issue happened in middle of a recorded video, loved it 
.
Definitely something fishy elsewhere than on my network.
There is a twitter thread that is growing about a similar error that has gone out.
I can reproduce it 100% of the time without a VPN.
FetchError: request to https://ic0.app/api/v2/canister/zfcdd-tqaaa-aaaaq-aaaga-cai/query failed, reason: connect ETIMEDOUT
This is the error from my typescript client above. I do not see this error from the browser.
Do you have the link the twitter thread?
I’ll then share the issue with the team internally (since I’m not the only weirdo NodeJS guy who face it 
)
I believe this is an issue between how fetch is implemented in Node 16 vs. Node 18. I ran into this issue when beta testing some IC software, and ran into similar issues originally when developing the CanDB frontend client sdk. It might be this plus a combination older version of the sdk being run that is expecting a particular node version?
Try downgrading from Node 18 to Node 16 and let me know if the issue still persists.
Also, what version of node are you currently using?
Hello Everyone … @icme is right, Node 16 seems happy, Node 18.14, not so happy … intermittent timeouts … usually in succession … fail fail fail fail, success, success, success, fail fail … etc … just confirmed latest @dfinity npm packages 0.15.3 …
Error in checkTokenResponse: ICPM Error: FetchError: request to https://ic0.app/api/v2/canister/5zc2i-mqaaa-aaaal-abcoa-cai/read_state failed, reason: connect ETIMEDOUT 2600:c00:2:100:5000:d0ff:fe62:c29b:443
Error in checkTokenResponse: ICPM Error: FetchError: request to https://ic0.app/api/v2/canister/5zc2i-mqaaa-aaaal-abcoa-cai/call failed, reason: connect ETIMEDOUT 2600:c00:2:100:5000:d0ff:fe62:c29b:443
notice too that the endpoints are different … @rckprtr 's was a ‘/query’ and this shows ‘/call’ and ‘/read_state’ … makes it seem like @icme said that it may be the new implementation of fetch … an api issue at the boundary?
I remember having tried to downgrade to v16 and still faced the issue but maybe my test wasn’t accurate (was an evening late…)
@kpeacock have you faced such an issue and maybe an idea?
And today is the first we have had such an issue on my end … not sure if it matters … @icme and I are in California … and I have a colleague in NY who has 0 issues with either 16 or 18 … maybe certain boundary nodes? … just guessing …
Thanks for the input. On my way home, late evening here but, will ping the BN team when I get there to forward the info
(update: done, msg forwarded)
I’ve never encountered ETIMEDOUT, personally, but I do less application development than you
Issue cleared up on my side: Node 18 with npm dfx 15
npm dfx 15? 
npm v8 and dfx v0.13.1?
Regardless of the NodeJS version go the error. I’ve forwarded following stacktrace and sample repo to reproduce the issue.
❯ npm run start
> @junobuild/example-node@0.0.1 start
> node index.mjs
This is a demo client in NodeJS
file:///Users/daviddalbusco/projects/juno/examples/node/node_modules/node-fetch/src/index.js:108
reject(new FetchError(`request to ${request.url} failed, reason: ${error.message}`, 'system', error));
^
FetchError: request to https://ic0.app/api/v2/canister/xo2hm-lqaaa-aaaal-ab3oa-cai/query failed, reason: connect ETIMEDOUT 2a0b:21c0:4003:2:5000:55ff:feb8:5f89:443
at ClientRequest.<anonymous> (file:///Users/daviddalbusco/projects/juno/examples/node/node_modules/node-fetch/src/index.js:108:11)
at ClientRequest.emit (node:events:525:35)
at TLSSocket.socketErrorListener (node:_http_client:494:9)
at TLSSocket.emit (node:events:513:28)
at emitErrorNT (node:internal/streams/destroy:151:8)
at emitErrorCloseNT (node:internal/streams/destroy:116:3)
at process.processTicksAndRejections (node:internal/process/task_queues:82:21) {
type: 'system',
errno: 'ETIMEDOUT',
code: 'ETIMEDOUT',
erroredSysCall: 'connect'
}
Node.js v18.12.1
sample:
git clone https://github.com/buildwithjuno/examples
cd examples/node
npm ci
npm run start
not sure if it helps, but this issue persists today, and intermittent as of the last few days and is a mainnet conversation …
FetchError: request to https://ic0.app/api/v2/canister/5zc2i-mqaaa-aaaal-abcoa-cai/call failed, reason: connect ETIMEDOUT 2600:c00:2:100:5000:d0ff:fe62:c29b:443
first try times out and second try it works …
thanks, I’ll share that error too
Following this as well, in US on the east coast, unable to duplicate the network timeout issues from here.
Peter, my run of your test seems happy with all flavors Node 18+. Have verified with 18.14/LTS, 18.13 (previous LTS), and 18.12.1 (the version in your example).
I’ve incurred no blips at all on repeated tries with all the above. We just don’t seem to having boundary/API quirks as you’re seeing farther west.
Node 16 does fail for me, but it seems like a different issue … undefined ‘Headers’ on invocation of your get() method(??)
Thanks Peter
