How to deal with Trello Rate Limit

Michel Szinavel

hello Comunity,

 

There is a topic that is getting stronger amoung us, that is RATE_LIMIT_EXCEEDED error by trello.

 

I know, the first question to answer is: "what are you doing with trello that you need more request?".

A: Into my business model, I must delegate some task to my board members and, I need to do that between 8am to 14pm, where we must build some cards with a given format (description -> add member -> add checklist -> add N items to that checklist)

 

Currently, we are using Ruby and, on top of that is: ruby-trello gem (https://github.com/jeremytregunna/ruby-trello). 

The main question here is: How you guys deals with this error when it occours? How to we prevent this to happend?

 

From now we have a "pre-request" to confirm if we have request left, if there isn't any, we sleep the thread for a while before try again. We know that this, if fact, is duplicating our normal rate but, it helps (or thats what I think).

https://developers.trello.com/docs/rate-limits

 

So, I override the base builder of the gem to ask for the: "x-rate-limit-api-token-remaining". Then, I sleep the thread for 5 sec before try again. The limit that Im asking for is something like: "is api token limit < 50 then sleep" and, even with that this error still happend!

 

I can strees this from different ways but, it doesn't show a pattern, not even a clue of why it falls. just... randomly falls... and, in all cases, the same error appears :
{"error":"RATE_LIMIT_EXCEEDED","message":"Exceeded rate limit to /1/member"}

 

Maybe at this point you may ask: "but it seems to be your user", but it falls even if I try with different developer's users.

 

I just need from you guys a little help on how to deal with it, every idea helps.

 

Thanks!

Oscar Triscon

It's hard to know for certain without seeing your code, but this is my guess:

Let's assume that you are issuing asynchronous requests, i.e. your code issues multiple requests at the same time, rather that issue a request, wait for a response, then issue another request. (This is quite likely: it'd be unusual to be able to issue 100 request/response/round trips to the Trello API in 10 seconds @~100ms/request.)

For the sake or argument, imagine that I issue 101 requests or more in an interval of 10 seconds. Further, imagine that the server is very slow today, and it takes more than 10 seconds to respond to every request. In this scenario, I will not receive a response with a header warning me about the rate until it's too late: I will already have issued too many requests and it doesn't matter that I freeze for 5 seconds.

This is an extreme, but it's just to make you realize that the information provided by the headers can arrive too late to be used for rate control. The fact that you get your error at random is because your system depends on the timing of the responses and other factors.

There's two typical solutions to this:

1. Do your own rate control. Write or use a throttler to issue your requests at an adequate rate.
2. Let the errors happen and handle them with an exponential backoff.