vendredi 18 juin 2021

Designing a boost asio retry network requests logic for the Telegram API

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_timers 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