Hello,
I’ve started to sporadically hit rate limit errors, even when using the Python SDK’s default retry settings. The solution for now is to increase the max_attempts argument above the default value of 3. However, I sense this will hit some diminishing returns for bursty workloads, such as when all my tests and deploys spin up at night during CI/CD runs.
It would be more useful to me if the 429 response returned some kind of Retry-After header or similar attribute in the response body in order to dictate when to retry next, or whether to even retry at all in the case a single query blows the rate limit. I’m not sure if this is possible given the rate limiting logic is based on operations per second. However, it would provide a more seamless experience when using an SDK that automatically respects a Retry-After value, and if the Retry-After value has a high likelihood of preventing another 429 error from occurring.