I need advice from the experts about the proper organization of the requests retrying logic for the Telegram API. Thanks in advance :).
Backend: I have a program in a multi-threaded environment that accepts messages asynchronously which are supposed to be sent as notifications to Telegram. Program is running on the boost::asio::io_context
(tg_context
variable), where I push the tasks to execute using the notifyAsync
method.
template <class T>
bool notifyAsync(T &&args) {
// Return false if exceeded the pended tasks amount.
auto action = [this, args = std::move(args)]() {
ActionResponseType resp = banana::api::call(connector, args); // blocking error-free request to the network
if (!resp) { //Retry the request }
};
tg_context.post(std::move(action));
return true;
}
Problem: There is a problem here due to the Telegram API limitations - messages limit per minute/second/chat/bot. Assuming 30 notifications is generated within 2-3 seconds, they will fail because of that. I'm thinking of the retrying logic with the exponentially increasing timeout and up to 3 attempts for each query.
Question: Can I simply start boost
deadline_timer
s with async_wait
for each failed query with tg_context.post
in the callback - won't that be a performance-killing solution? If that's not the right way - what is your experience-based advice for solving such cases? Please, don't suggest using multiple bots - normally, I won't receive a lot of notifications, however, retries logic is important.
Updated: Another solution I am thinking of is analyzing the failure reason and pausing the whole sending logic if 429 Too Many Requests
is received.
Aucun commentaire:
Enregistrer un commentaire