In terms of Telegram bot API the maximum polling time of getUpdates is referred to as timeout. That is if there are pending updates, Telegram will return them immediately. In the other case, it will wait for timeout seconds and then answer with an empty list.
The telegram-bot Rust library has its own notion of timeouts. getUpdates' timeout is dubbed error_delay, whereas the word timeout is used for HTTP request timeout (as parameter for tokio::time::timeout wrapper).
The default value of error_delay is 500ms, which is effectively zero because timeout must be specified in seconds. Telegram documentation discourages zero timeouts. Some bot frameworks I've used default this value to 30 seconds.
Another fact about error_delay is that it has nothing to do with errors. The same value is used in case of successful and faulty previous request.
Apart from that these peculiarities are confusing by nature, the corresponding documentation is incorrect. It claims that timeout corresponds with timeout field in getUpdates and error_delay is a delay between erroneous request and next request.
I suggest bringing implementation in line with documentation.
In terms of Telegram bot API the maximum polling time of
getUpdatesis referred to astimeout. That is if there are pending updates, Telegram will return them immediately. In the other case, it will wait for timeout seconds and then answer with an empty list.The telegram-bot Rust library has its own notion of timeouts. getUpdates' timeout is dubbed
error_delay, whereas the wordtimeoutis used for HTTP request timeout (as parameter fortokio::time::timeoutwrapper).The default value of
error_delayis 500ms, which is effectively zero because timeout must be specified in seconds. Telegram documentation discourages zero timeouts. Some bot frameworks I've used default this value to 30 seconds.Another fact about
error_delayis that it has nothing to do with errors. The same value is used in case of successful and faulty previous request.Apart from that these peculiarities are confusing by nature, the corresponding documentation is incorrect. It claims that
timeoutcorresponds with timeout field ingetUpdatesanderror_delayis a delay between erroneous request and next request.I suggest bringing implementation in line with documentation.