Node causes Fatal error after upgrade to NR 3.1 and Node 20.8.1 (from NR 3.0.x and node 16.x.x.)

[WombatHollow]

NR 3.1.0 Node 20.8.1 Raspberry Pi 3B, running Bullseye (just performed full update) Linux version 6.1.21-v7+ (dom@buildbot) (arm-linux-gnueabihf-gcc-8 (Ubuntu/Linaro 8.4.0-3ubuntu1) 8.4.0, GNU ld (GNU Binutils for Ubuntu) 2.34) #1642 SMP Mon Apr 3 17:20:52 BST 2023

After performing update, the Node throughs the following error in the Log Disable all Nodes except BOT and Errors stop being reported in the debug screen Enabled Control Node , still no error Enable a Recieve or Send node and errors return

Eventually Node-red appears to stop and restart.

Only recovery is to node-red-stop then Node-red --safe and disable BOT and related Nodes

Example Log

23 Oct 20:05:59 - [warn] [telegram bot:1637792c.79a397] EFATAL: AggregateError
23 Oct 20:05:59 - [warn] [telegram bot:1637792c.79a397] Unknown error. Trying again.
Unhandled rejection RequestError: AggregateError
    at new RequestError (/home/pi/.node-red/node_modules/request-promise-core/lib/errors.js:14:15)
    at plumbing.callback (/home/pi/.node-red/node_modules/request-promise-core/lib/plumbing.js:87:29)
    at Request.RP$callback [as _callback] (/home/pi/.node-red/node_modules/request-promise-core/lib/plumbing.js:46:31)
    at self.callback (/home/pi/.node-red/node_modules/request/request.js:185:22)
    at Request.emit (node:events:514:28)
    at Request.onRequestError (/home/pi/.node-red/node_modules/request/request.js:877:8)
    at ClientRequest.emit (node:events:514:28)
    at TLSSocket.socketErrorListener (node:_http_client:495:9)
    at TLSSocket.emit (node:events:514: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:2    

[windkh]

Hm I use node 18.12.2... never tried 20

[WombatHollow]

I see on https://nodejs.org/en/download that 20.8.1 is now LTS. happened in last 24 hours. Will try and uninstall Node 20 and install 18 and see if that fixes this problem but very busy at present

[WombatHollow]

I just completely removed this Node from my flow and script, then added it back from palette and added one sender node (and BOT). Did not fix but at least the CPU hogging I say earlier which forced me to edit in safe mode didn't comeback. From the LOG 25 Oct 19:24:58 - [warn] [telegram bot:d3b9bd26579abec8] EFATAL: AggregateError 25 Oct 19:24:58 - [warn] [telegram bot:d3b9bd26579abec8] Unknown error. Trying again. Unhandled rejection RequestError: AggregateError at new RequestError (/home/pi/.node-red/node_modules/request-promise-core/lib/errors.js:14:15) at plumbing.callback (/home/pi/.node-red/node_modules/request-promise-core/lib/plumbing.js:87:29) at Request.RP$callback [as _callback] (/home/pi/.node-red/node_modules/request-promise-core/lib/plumbing.js:46:31) at self.callback (/home/pi/.node-red/node_modules/request/request.js:185:22) at Request.emit (node:events:514:28) at Request.onRequestError (/home/pi/.node-red/node_modules/request/request.js:877:8) at ClientRequest.emit (node:events:514:28) at TLSSocket.socketErrorListener (node:_http_client:495:9) at TLSSocket.emit (node:events:514: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)

The two Nodes are (I removed my telegram username) [ { "id": "fe4de8121bbd1925", "type": "telegram sender", "z": "8689ea2a.fc96b8", "d": true, "name": "from Wombat Hollow", "bot": "d3b9bd26579abec8", "haserroroutput": true, "outputs": 2, "x": 540, "y": 100, "wires": [ [ "76c969b3.026ab8" ], [ "1712d158.789bff" ] ] }, { "id": "d3b9bd26579abec8", "type": "telegram bot", "d": true, "botname": "WombatHollow_bot", "usernames": "xxxxxxxxxx", "chatids": "", "baseapiurl": "", "updatemode": "polling", "pollinterval": "1200", "usesocks": false, "sockshost": "", "socksprotocol": "socks5", "socksport": "6667", "socksusername": "anonymous", "sockspassword": "", "bothost": "", "botpath": "", "localbotport": "8443", "publicbotport": "8443", "privatekey": "", "certificate": "", "useselfsignedcertificate": false, "sslterminated": false, "verboselogging": true } ]

OK, now to uninstall Node 20 and try Node 18... if I can

[windkh]

I can upgrade and test it, too

[WombatHollow]

Just did the backwards step and reinstalled NR with node 18.15.2 and the Telegrambot node works. So the problem appears to be a compatibility issue with node 20.8.1. Now to sort out why the Command Nodes do not work (that may be another issue). Sender, Receiver nodes work OK.

[windkh]

I updated to Node-Red v3.1.1 using docker image from here https://hub.docker.com/r/nodered/node-red:

23 Jan 18:17:53 - [info] Node-RED version: v3.1.3 23 Jan 18:17:53 - [info] Node.js version: v16.20.2 23 Jan 18:17:53 - [info] Linux 5.10.60-qnap x64 LE

Everything works here. Will try to upgrade nodejs on my windows

[dbowerman]

Same issue

Nodejs v20.5.1

Node-red v3.1.7

2024-03-26T15:41:51.940303+11:00 dave-linux Node-RED[888]: Unhandled rejection RequestError: AggregateError 2024-03-26T15:41:51.940617+11:00 dave-linux Node-RED[888]: at new RequestError (/home/dave/.node-red/node_modules/request-promise-core/lib/errors.js:14:15) 2024-03-26T15:41:51.940727+11:00 dave-linux Node-RED[888]: at Request.plumbing.callback (/home/dave/.node-red/node_modules/request-promise-core/lib/plumbing.js:87:29) 2024-03-26T15:41:51.940807+11:00 dave-linux Node-RED[888]: at Request.RP$callback [as _callback] (/home/dave/.node-red/node_modules/request-promise-core/lib/plumbing.js:46:31) 2024-03-26T15:41:51.940894+11:00 dave-linux Node-RED[888]: at self.callback (/home/dave/.node-red/node_modules/request/request.js:185:22) 2024-03-26T15:41:51.940996+11:00 dave-linux Node-RED[888]: at Request.emit (node:events:514:28) 2024-03-26T15:41:51.941134+11:00 dave-linux Node-RED[888]: at Request.onRequestError (/home/dave/.node-red/node_modules/request/request.js:877:8) 2024-03-26T15:41:51.941288+11:00 dave-linux Node-RED[888]: at ClientRequest.emit (node:events:514:28) 2024-03-26T15:41:51.941402+11:00 dave-linux Node-RED[888]: at TLSSocket.socketErrorListener (node:_http_client:495:9) 2024-03-26T15:41:51.941538+11:00 dave-linux Node-RED[888]: at TLSSocket.emit (node:events:514:28) 2024-03-26T15:41:51.941634+11:00 dave-linux Node-RED[888]: at emitErrorNT (node:internal/streams/destroy:151:8) 2024-03-26T15:41:51.941713+11:00 dave-linux Node-RED[888]: at emitErrorCloseNT (node:internal/streams/destroy:116:3) 2024-03-26T15:41:51.941792+11:00 dave-linux Node-RED[888]: at processTicksAndRejections (node:internal/process/task_queues:82:21)

[windkh]

please try again with please try with new version 16.0.0

[spidgrou]

just tested new 16.00 version. With nodejs 20.14 still non working

[dbowerman]

16.0.1 on Node v20.5.1

2024-06-26T10:21:40.680484+10:00 dave-linux Node-RED[295624]: Unhandled rejection RequestError: AggregateError

2024-06-26T10:21:40.680594+10:00 dave-linux Node-RED[295624]: at new RequestError (/home/dave/.node-red/node_modules/request-promise-core/lib/errors.js:14:15)

2024-06-26T10:21:40.680659+10:00 dave-linux Node-RED[295624]: at Request.plumbing.callback (/home/dave/.node-red/node_modules/request-promise-core/lib/plumbing.js:87:29)

2024-06-26T10:21:40.680721+10:00 dave-linux Node-RED[295624]: at Request.RP$callback [as _callback] (/home/dave/.node-red/node_modules/request-promise-core/lib/plumbing.js:46:31)

2024-06-26T10:21:40.680803+10:00 dave-linux Node-RED[295624]: at self.callback @./request/request.js:183:22 @./request/request.js:183:22> )

2024-06-26T10:21:40.680889+10:00 dave-linux Node-RED[295624]: at Request.emit (node:events:514:28)

2024-06-26T10:21:40.680962+10:00 dave-linux Node-RED[295624]: at Request.onRequestError @./request/request.js:869:8 @./request/request.js:869:8> )

2024-06-26T10:21:40.681050+10:00 dave-linux Node-RED[295624]: at ClientRequest.emit (node:events:514:28)

2024-06-26T10:21:40.681119+10:00 dave-linux Node-RED[295624]: at TLSSocket.socketErrorListener (node:_http_client:495:9)

2024-06-26T10:21:40.681204+10:00 dave-linux Node-RED[295624]: at TLSSocket.emit (node:events:514:28)

2024-06-26T10:21:40.681295+10:00 dave-linux Node-RED[295624]: at emitErrorNT (node:internal/streams/destroy:151:8)

2024-06-26T10:21:40.681384+10:00 dave-linux Node-RED[295624]: at emitErrorCloseNT (node:internal/streams/destroy:116:3)

2024-06-26T10:21:40.681470+10:00 dave-linux Node-RED[295624]: at processTicksAndRejections (node:internal/process/task_queues:82:21)

From: spidgrou @.> Sent: Monday, June 24, 2024 1:38 PM To: windkh/node-red-contrib-telegrambot @.> Cc: Dave Bowerman @.>; Comment @.> Subject: Re: [windkh/node-red-contrib-telegrambot] Node causes Fatal error after upgrade to NR 3.1 and Node 20.8.1 (from NR 3.0.x and node 16.x.x.) (Issue #343)

just tested new 16.00 version. With nodejs 20.14 still non working

— Reply to this email directly, view it on GitHub https://github.com/windkh/node-red-contrib-telegrambot/issues/343#issuecomment-2185522985 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AAX6MHDBL7OLTB3IMWC34XTZI6IBTAVCNFSM6AAAAAA6LYC7RSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCOBVGUZDEOJYGU . You are receiving this because you commented. https://github.com/notifications/beacon/AAX6MHHINJJQB5BEQNMTH3TZI6IBTA5CNFSM6AAAAAA6LYC7RSWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTUCIRXSS.gif Message ID: @. @.> >

[windkh]

maybe this solves the problem... will try to fix it https://github.com/yagop/node-telegram-bot-api/issues/1136

[WombatHollow]

Hi, how are you going with a fix? I have just built up a new Raspi 3B with latest versions of NR (4.0.2) and node (22.7) and v16.0.2 of node-red-contrib-telegrambot and unfortunately the original problem still exists. I reinstalled node 18.20 (remained with NR 4.0.2) and problem went away. So we cannot move away from node 18 LTS and it will eventually not be supported by later NR. I still have this Raspi set up as a test rig, so can use it to test any fixes against Node 20 or 22 if it helps.

I did see these warnings in NR when I installed node-red-contrib-telegrambot through the pallete into NR 4.0.2. Mainly depreciation warnings

`----------------------------------------------------------- 2024-09-03T09:20:27.248Z Install : node-red-contrib-telegrambot 16.0.2

2024-09-03T09:20:26.969Z npm install --no-audit --no-update-notifier --no-fund --save --save-prefix=~ --omit=dev --engine-strict node-red-contrib-telegrambot@16.0.2 2024-09-03T09:20:58.573Z [err] npm warn deprecated har-validator@5.1.5: this library is no longer supported 2024-09-03T09:21:05.296Z [err] npm warn deprecated uuid@3.4.0: Please upgrade to version 7 or higher. Older versions may use Math.random() in certain circumstances, which is known to be problematic. See https://v8.dev/blog/math-random for details. 2024-09-03T09:21:05.623Z [err] npm warn deprecated request@2.88.2: request has been deprecated, see https://github.com/request/request/issues/3142 2024-09-03T09:21:10.787Z [out] 2024-09-03T09:21:10.787Z [out] added 157 packages in 43s 2024-09-03T09:21:10.839Z rc=0`

[thomasvnl]

Hi, how are you going with a fix? I have just built up a new Raspi 3B with latest versions of NR (4.0.2) and node (22.7) and v16.0.2 of node-red-contrib-telegrambot and unfortunately the original problem still exists. I reinstalled node 18.20 (remained with NR 4.0.2) and problem went away. So we cannot move away from node 18 LTS and it will eventually not be supported by later NR. I still have this Raspi set up as a test rig, so can use it to test any fixes against Node 20 or 22 if it helps.

I did see these warnings in NR when I installed node-red-contrib-telegrambot through the pallete into NR 4.0.2. Mainly depreciation warnings

`----------------------------------------------------------- 2024-09-03T09:20:27.248Z Install : node-red-contrib-telegrambot 16.0.2

2024-09-03T09:20:26.969Z npm install --no-audit --no-update-notifier --no-fund --save --save-prefix=~ --omit=dev --engine-strict node-red-contrib-telegrambot@16.0.2 2024-09-03T09:20:58.573Z [err] npm warn deprecated har-validator@5.1.5: this library is no longer supported 2024-09-03T09:21:05.296Z [err] npm warn deprecated uuid@3.4.0: Please upgrade to version 7 or higher. Older versions may use Math.random() in certain circumstances, which is known to be problematic. See https://v8.dev/blog/math-random for details. 2024-09-03T09:21:05.623Z [err] npm warn deprecated request@2.88.2: request has been deprecated, see request/request#3142 2024-09-03T09:21:10.787Z [out] 2024-09-03T09:21:10.787Z [out] added 157 packages in 43s 2024-09-03T09:21:10.839Z rc=0`

I can concur that I had the same issue with the NodeRED 4.0.2 docker container. Had to revert to the 3.1.x container to get it working again.

[WombatHollow]

As Karl-Heinz appears to be off line at present (we all have other commitments) I thought I would try to help as I have a Raspi setup and can use to experiment. Looking at [https://github.com/yagop/node-telegram-bot-api/issues/1136] Karl mentioned above, it appears we need to force IPv4 usage (when we have this problem). So I will add this line family = 4, into Karl's code at the following ` if (this.useSocks) { let socksprotocol = n.socksprotocol || 'socks5'; let agentOptions = { hostname: n.sockshost, port: n.socksport, protocol: socksprotocol, //family: 4, // type: 5, timeout: 5000, // ms <-- does not really work }; ' // more code here I have ommited ' if (n.socksusername !== '') { agentOptions.username = n.socksusername; }

        if (n.sockspassword !== '') {
            agentOptions.password = n.sockspassword;
        }

        this.socksRequest = {
            agentClass: SocksProxyAgent,
            agentOptions: agentOptions,
            pool: {},
        };
    }

and then it is used in this.createTelegramBotForPollingMode = function () {
at const options = { polling: polling, baseApiUrl: this.baseApiUrl, testEnvironment: this.testEnvironment, request: this.socksRequest, }; newTelegramBot = new telegramBotEx(this.token, options); ` The issue I see is that this.socksRequest will only be defined if Socks are being used. So I propose to also add a line before that should this.socksRequest not be defined, the define 'options.request.agentOptions = 4'

Any thoughts or am I missing something. I will set this up (first timer for inserting my 'own' node into Node-red) on my spare Raspi 3B with mode 18, then 20 then 22 and see if the Errors go away. If this fixes the problem, then look to a better method to add it to Karl's node (maybe a IPv4, IPv5 tick boxes in bot dialogue window?).

[windkh]

Hi all … sorry for delay. I am busy all the time and was not able to shift priorities to this project. Maybe next week when the weather will turn bad I will find some minutes to investigate that issue.

[windkh]

I installed Node-RED version: v3.1.9 Node.js version: v20.17.0 Started node red and added two telegram nodes: everything works when running from my Windows Laptop.

Next step will be updating to 20.17.0 on my raspi to see if that causes the same problem.

[WombatHollow]

Karl, Progress. I set up my spare Raspi3B with NR 4.0.2, Node 18 and NPM 10.8.2. I then copied v16.0.2 of node-red-contrib-telegrambot into a directory on the pi, modified package.json to remove repository: object (didn't want it interfering with your github) and it worked as normal. I then upgraded to node 20.17.0 using the NR Raspbi install script with --node20 flag and restarted NR and the orignal errors appeared. I then inserted the following code after line 383 of your 99-telegrambot.js options.request ={ agentOptions :{ family : 4 } } ; // as per issue 343 this forces IPv4 be used Now the node installs and works correctly in my setup.

Some Observations

My setup does not use SOCKs so the code as written will overwrite and SOCKs settings in options.request When not using socks the options sent to node-telegrambot has in the second parameter "options.request = undefined" could this undefined be the issue rather than not exist? { polling: { autoStart: true, interval: 300, params: { timeout: 10 } }, baseApiUrl: '', testEnvironment: false, request: undefined }

My system at the main router and modem does not have IPv6 enabled but the Raspi shows from "ip -a"

_1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host noprefixroute valid_lft forever preferred_lft forever 2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000 link/ether b8:27:eb:6c:40:4b brd ff:ff:ff:ff:ff:ff 3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether b8:27:eb:39:15:1e brd ff:ff:ff:ff:ff:ff inet 10.0.0.231/24 brd 10.0.0.255 scope global dynamic noprefixroute wlan0 valid_lft 6741sec preferred_lft 6741sec inet6 fe80::7425:35fb:12f8:1e45/64 scope link noprefixroute valid_lft forever preferredlft forever

in Node 20 could this be fooling the node to think there is a IPv6 available, when it doesn't connect through?

Hope this helps, happy to trial any improvements. In meantime I will play with this a bit more to improve.

[WombatHollow]

I have found the Cause and interim solution

Home network has no IPv6 connection but Raspi has IPv6 enabled, even a IPv6 address (command ip a will show). DIsable IPv6 on Raspi (for example by [https://fleetstack.io/blog/disable-ipv6-raspberry-pi#:~:text=How%20to%20Disable%20IPv6%20on%20Your%20Raspberry%20Pi,Reboot%20Your%20Raspberry%20Pi%20...%206%20Conclusion%20] ) and node-red-contrib-telegrambot now works with Node 20. I would hypothesis that node20 changed preferred IP and how it determines if ipv6 is available, rather than checking a live IPv6 connection, it takes the existence of a IPv6 address as IPv6 exists.

[windkh]

Hi @WombatHollow thanks for your help. I recently upgraded to nr4 and nodejs20 and everything worked on my laptop. And yes I have IPV6 disabled in my router. I guess if that is a general problem then it should also be reproducable not only on a raspi. I have one here but debugging remotely must be set up first. So I try to enable IPV6 on my laptop and then we will see...

[WombatHollow]

On W10 IPv6 is normally enabled, figure shows where to disable or enable in case your laptop already has IPv6 disabled. And then again node may use different indicators between Linux and W10 to determine IPv6 availability.

[windkh]

Please try version 16.1.0 and let me know if it changed something

[WombatHollow]

Thanks for that Karl. I can confirm that that fix works on my development Raspi3B+ with IPv6 enabled 16 Sep 18:54:33 - [info] Node-RED version: v4.0.2 16 Sep 18:54:33 - [info] Node.js version: v20.17.0 16 Sep 18:54:33 - [info] Linux 6.6.31+rpt-rpi-v8 arm64 LE (Bookworm)

But it works on all 3 settings, aka IPv4, IPv6 and any which supprised me. I see in your code that on 'any' that you set agentOptions.family = this. addressFamily and this.addressFamily is now a string "4", "6" or "" rather than undefined when SOCKS is not enabled in v 16.0.2?

I then updated my live system a Raspi 3B (no +) with IPv6 enabled to NR 4.0.2 and Node 20.17.0 and 16.1.0 of your node, restarted NR (still on Bullseye) and the problem reappeared. I edited the bot to IPv4 and problem remained so I did a full reboot on the RasPi and the fault disappears. Now that Pi also works OK with any setting of agentOptions.family (4, 6 or any)

So all now good, I am working with NR 4.0.2, node 20 and bookworm

I also tested my modified version of your .js file on node 22 and saw same behaviour as node 20 so not expecting probles when we go to node 22. But I will stick with Node 20 for the present time as Node 22 is still throwing a few depreciation faults etc. I guess they will be sorted before NR officially supports Node 22 when it goes to LTS.

Ian aka Wombat Hollow,

fyi Wombat Hollow is our property name and my NR implemtation is all about automation of our power, water, heating etc here as we are fully off -grid except for Starlink for data, and a driveway to the local road for physical access)

On Mon, 16 Sept 2024 at 02:15, Karl-Heinz Wind @.***> wrote:

Please try version 16.1.0 and let me know if it changed something

— Reply to this email directly, view it on GitHub https://github.com/windkh/node-red-contrib-telegrambot/issues/343#issuecomment-2351660641, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGDP7BS47DHBT533EQPYHHTZWWXBHAVCNFSM6AAAAAA6LYC7RSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNJRGY3DANRUGE . You are receiving this because you were mentioned.Message ID: @.***>

[windkh]

Hi Ian (@WombatHollow), first of all "any" sets family to "undefined".

Ok I am glad that it works now. On the other hand I do not understand why it works regardless of what you choose in the configuration. Can we try to eliminate that?

I would like to fully understand the problem and the solution.

[windkh]

@WombatHollow can you try to use a socks proxy. I am curious if that works, too?

[WombatHollow]

Karl, I did a bit more work and have discovered my 16.2.0 'worked' for IPv4, IPv6 and any. The answer is when you deploy, then those new settings do get placed into options....family and applied to newTelegramBot but polling continues with the old settings! aka no change. If I stop and start NR then the new settings are applied and as expected IPv4 works without error whilst IPv6 or any do not work.

So only the following worked { polling: { autoStart: true, interval: 300, params: { timeout: 10 } }, baseApiUrl: '', testEnvironment: false, request: { agentOptions: { family: 4 } } } it must have .family = 4

A minor error, for 'any', .family = 0 for it to be effective. .family requires a number 0, 4 or 6

As for SOCKs, I have never used proxies or SOCKs so that will require a bit more research from me

On Tue, 17 Sept 2024 at 05:41, Karl-Heinz Wind @.***> wrote:

@WombatHollow https://github.com/WombatHollow can you try to use a socks proxy. I am curious if that works, too?

— Reply to this email directly, view it on GitHub https://github.com/windkh/node-red-contrib-telegrambot/issues/343#issuecomment-2353767882, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGDP7BSHF4YJU7W5X6Z4TQLZW4X5TAVCNFSM6AAAAAA6LYC7RSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNJTG43DOOBYGI . You are receiving this because you were mentioned.Message ID: @.***>

[gtalusan]

I've been seeing some frequent EFATAL: AggregateError with the node-red docker (NR 4.0.2, node v20.17.0) and node-red-contrib-telegrambot v16.1.0. I've been running the container for a <4 months and only noticed the error within the past few weeks.

[WombatHollow]

I've been seeing some frequent EFATAL: AggregateError with the node-red docker (NR 4.0.2, node v20.17.0) and node-red-contrib-telegrambot v16.1.0. I've been running the container for a <4 months and only noticed the error within the past few weeks.

@gtalusan , if what you are seeing is this problem, a work around is to either disable IPv6 on your nodered host machine, or in the bot Node set 'IP address Family' to IPv4 and then restart the machine. The issue is in some NODEjs libraries that this Node uses, it doesn't properly test if IPv6 works before using. It just sees IPv6 is enabled on host machine but if IPv6 is not enabled in network firewall/router then the code fails. If that doesn't fix this may be another ussue