Hi @dmorrow,
thanks for sharing this documentation, which is very useful.
I have a question on the Rate Limiting documentation for Jira.
The documentation states the following:
You can retry a failed request if:
- It is safe to do so from the perspective of the API (e.g. the API being called is idempotent).
- A small retry threshold has not been reached.
- The response indicates a retry is appropriate (
Retry-After
header and/or 429
status).
I assume that means if all conditions are met.
Does it mean that an app should retry any REST call if and only if it receives either a 429 error or a Retry-After header? And thus that any other error (403, 500, 503, 509, which are also returned by certain REST endpoints in overloading situations) should not be retried unless they are accompanied by a Retry-After header? A common error code when Jira is overloaded is a 403 error with no error message in the body (in fact, an HTML response body instead of a JSON response body), usually indicating a DB connection pool error. Are these errors marked with a Retry-After header?
In general, it would be nice to include in the documentation a full, validated pseudo-code algorithm showing how exactly apps should handle errors related to rate limits, including how to identify them (which is not shown in the current algorithm). For that, you’d need to test all REST endpoints one by one by throwing a million requests at them until they fail, and check the error code they return then and add that case to the algorithm.
Thanks,
David