FLOOD_WAIT_* not handled well

[himselfv]

I'm using this through spectrum2 -> purple-telegram -> tgl. When purple-telegram makes a lot of requests at the start sometimes it starts getting FLOOD_WAIT_3 and finally something like FLOOD_WAIT_375.

I've looked at the code, and it seems this is supposed to be handled in tgl, by rescheduling the request to a later time.

// queries.c > tglq_query_error()
TLS->timer_methods->insert (q->ev, wait);

But I've added printfs in timer callbacks and the timer is immediately freed after being rescheduler. Later in the same tgl_query_error this indeed happens:

if (res <= 0) {
      tfree (q->data, q->data_len * 4);
      TLS->timer_methods->free (q->ev);
}

res is 0 from the start of the function and nothing in FLOOD_WAIT branch changes it. In other similar cases where the function handles the error, it sets res to 1. Maybe it should also be set to 1 here?

Tentatively I've added

    case 420:
    case 500:
    default: {
        //...
        error_handled = 1;
        res = 1;  // <----
      }
      break;

Now the requests are called after a timeout like they should! But something weird is going on. They never seem to actually execute. There's an "Alarm query ..." in log, then timer callbacks showing the event being rescheduled 6 seconds ahead, and that's it. 6 seconds later, the same again.

queries.c > alarm_query() has two routes which I'm not sure mean what, I've checked that the execution goes the first route. This is where I'm stuck so far. Any ideas? Thank you.

Also I don't know Telegram protocol very well so maybe I'm wrong, but is it enough to just reschedule the query that triggered the FLOOD_WAIT? Shouldn't the following queries be also delayed?

I mean, say you have 20 queries coming one after another and Telegram says FLOOD_WAIT on the sixth one, this reschedules it N seconds later, but wouldn't tgl still try to send queries number 6, 7 and so on? I imagine if this was all a single connection, it would get FLOOD_WAIT for each of them, and by the time the first rescheduled request fires and is re-sent the connection is still flooded (since each successive FLOOD_WAIT shifts the wait window further), and it'll get FLOOD_WAIT again and so on. I'm not actually observing this, just wondering.