Join 34,000+ subscribers and receive articles from our blog about software quality, testing, QA and security.
 

429 (too many requests) - Can multiple threads/processes result in a deadlock?


#1

Application A and Application B are both accessing the TestRail API using the same credentials. Application A receives a 429 response and goes into a wait state for the specified Retry-After value. Application B doesn’t know application A received a 429 and sends another request a few seconds later, receiving it’s own 429.

Does Application B’s request extend the amount of time Application A must wait before it can send a request? If so, do you have any recommended strategies for keeping multiple applications from causing a deadlock with each other?


#2

Hi there,

Thank you for the post. The API is limited to a few requests per second on TestRail Hosted (per TestRail instance, of course). This isn’t an issue for most customers in practice but if you plan to add thousands of test results per hour, it may be a better idea to use a local installation of TestRail instead. You will also benefit from the reduced latency if the TestRail installation is located on a local network in this case.

Please let me know in case you have any further questions. Also, feel free to contact us via email at contact@gurock.com if you would like to discuss this in more detail.


#3

Hi Marty,

Thank you for the quick response.

Our volume is quite a bit lower than thousands per hour, but I have hit 429 errors posting a couple-hundred results at once. We also have some tasks that touch up data from time to time via the API that run in a separte process. I’m afraid I’m still not clear whether the API retry delay is fixed at the point where the first 429 is received or whether another call before the timeout will extend the delay time. Could you please clarify that behavior?

Thanks for your help.

David


#4

Hey David,

Thank you for the response. This really depends on what method you are using with the API. If you are using a bulk method this wold be better i.e., add_results as this constitutes one API call rather than add_result which would be one request per PUT request.