yagop / node-telegram-bot-api

Telegram Bot API for NodeJS
MIT License
8.4k stars 1.52k forks source link

Unhandled rejection TimeoutError: operation timed out #170

Closed ghost closed 5 years ago

ghost commented 8 years ago

Unhandled rejection TimeoutError: operation timed out at afterTimeout (/Users/bogdanmedvedev/Documents/telegrambBot-webfin/node_modules/request-promise/node_modules/bluebird/js/main/timers.js:16:15) at Timeout.timeoutTimeout (/Users/bogdanmedvedev/Documents/telegrambBot-webfin/node_modules/request-promise/node_modules/bluebird/js/main/timers.js:59:9) at tryOnTimeout (timers.js:224:11) at Timer.listOnTimeout (timers.js:198:5)

dirathea commented 8 years ago

I think I've got similar issue with this..

16 Jul 2016 11:54:32.431 145 <190>1 2016-07-16T04:54:32.035350+00:00 app web.1 - - { [Error: connect ETIMEDOUT some.server.ip.address:443] » 16 Jul 2016 11:54:32.431 117 <190>1 2016-07-16T04:54:32.035351+00:00 app web.1 - - code: 'ETIMEDOUT', » 16 Jul 2016 11:54:32.431 118 <190>1 2016-07-16T04:54:32.035352+00:00 app web.1 - - errno: 'ETIMEDOUT', » 16 Jul 2016 11:54:32.431 118 <190>1 2016-07-16T04:54:32.035352+00:00 app web.1 - - syscall: 'connect', » 16 Jul 2016 11:54:32.431 126 <190>1 2016-07-16T04:54:32.035353+00:00 app web.1 - - address: 'some.server.ip.address', » 16 Jul 2016 11:54:32.431 111 <190>1 2016-07-16T04:54:32.035354+00:00 app web.1 - - port: 443 }, » 16 Jul 2016 11:54:32.431 116 <190>1 2016-07-16T04:54:32.035354+00:00 app web.1 - - isOperational: true, » 16 Jul 2016 11:54:32.431 114 <190>1 2016-07-16T04:54:32.035355+00:00 app web.1 - - code: 'ETIMEDOUT', » 16 Jul 2016 11:54:32.431 115 <190>1 2016-07-16T04:54:32.035355+00:00 app web.1 - - errno: 'ETIMEDOUT', » 16 Jul 2016 11:54:32.431 115 <190>1 2016-07-16T04:54:32.035356+00:00 app web.1 - - syscall: 'connect', » 16 Jul 2016 11:54:32.431 123 <190>1 2016-07-16T04:54:32.035356+00:00 app web.1 - - address: 'some.server.ip.address', » 16 Jul 2016 11:54:32.431 107 <190>1 2016-07-16T04:54:32.035357+00:00 app web.1 - - port: 443 }

zigzag-way commented 8 years ago

I`ve got the same

qadirsuh commented 8 years ago

Me too got this

Unhandled rejection RequestError: Error: connect ETIMEDOUT 149.154.167.200:443 at new RequestError (/Users/qadirhussain/Desktop/Development/nodeJS/telegram_bot/telegram-node-bot-1/node_modules/request-promise/lib/errors.js:11:15) at Request.RP$callback [as _callback] (/Users/qadirhussain/Desktop/Development/nodeJS/telegram_bot/telegram-node-bot-1/node_modules/request-promise/lib/rp.js:60:32) at self.callback (/Users/qadirhussain/Desktop/Development/nodeJS/telegram_bot/telegram-node-bot-1/node_modules/request/request.js:187:22) at emitOne (events.js:96:13) at Request.emit (events.js:188:7) at Request.onRequestError (/Users/qadirhussain/Desktop/Development/nodeJS/telegram_bot/telegram-node-bot-1/node_modules/request/request.js:813:8) at emitOne (events.js:96:13) at ClientRequest.emit (events.js:188:7) at TLSSocket.socketErrorListener (_http_client.js:308:9) at emitOne (events.js:96:13) at TLSSocket.emit (events.js:188:7) at emitErrorNT (net.js:1272:8) at _combinedTickCallback (internal/process/next_tick.js:74:11) at process._tickCallback (internal/process/next_tick.js:98:9)

LordJZ commented 8 years ago

Any update on this?

The timeout issue is basically breaking the bot receiving messages completely. After timeout it just spins on this error forever.

app-0     at Timer.listOnTimeout [as ontimeout] (timers.js:110:15)
app-0 Unhandled rejection TimeoutError: operation timed out
app-0     at afterTimeout (/home/pi/acid/acidhost/node_modules/node-telegram-bot-api/node_modules/request-promise/node_modules/bluebird/js/main/timers.js:16:15)
app-0     at timeoutTimeout (/home/pi/acid/acidhost/node_modules/node-telegram-bot-api/node_modules/request-promise/node_modules/bluebird/js/main/timers.js:59:9)
app-0     at Timer.listOnTimeout [as ontimeout] (timers.js:110:15)

I am creating bot like this: (recommended in duplicate #107)

var bot = new Bot(config.telegram.token, { polling: { interval: 2000, timeout: 10 } });

Version:

"node-telegram-bot-api": "^0.23.3",
edBaev commented 8 years ago

+

mrummuka commented 8 years ago

I also keep getting this quite constantly which is quite annoying as it is filling the logs. It also seems like it breaks the connection, although I'm not yet 100% sure does it do that (I have several node-red flows in parallel with different telegrambot accounts, and although some of them seems unusable when this problem occurs, I haven't yet managed to fully verify that).

In any case, if the revkov's commit (4a7c339) fixes this, could this me merged and published quite soon?

LordJZ commented 8 years ago

I can confirm that https://github.com/yagop/node-telegram-bot-api/commit/4a7c33976e178a4b5f6e41c73e6db3c931b6c9c2 does NOT fix the problem, and yes, the timeout does break the connection with that bot permanently.

dirathea commented 8 years ago

According to Timeout, I've been talked with bot support about this issues, and they suggest me to:

  1. Increase the timeout up to 65
  2. Move to another server on EU (On that time, I'm using Heroku on US region)

And yes, those suggestion is works, my sambungkatabot never got this issue again

hems commented 7 years ago

@dirathea even if it works, still the library shouldn't lose connection forever or we should be able to catch the error and ask it to connect again?

dirathea commented 7 years ago

@hems yeah the libs should add recovery mechanism about this one. What do you think @yagop / @gochomugo ?

GochoMugo commented 7 years ago

What recovery measure do you suggest?

LordJZ commented 7 years ago

Continue polling obviously?

GochoMugo commented 7 years ago

And at what point should we consider polling to have failed?

hems commented 7 years ago

@GochoMugo well we catch the error and try to pool again then it's up to the application to decide when to stop pooling, by calling stopPooling or something among those lines..

When the application is in production we need some sort of retry/recovery logic otherwise the bot just seems to be offline and not reply anymore when a simple "restart" would have sorted the situation.