elastic-transport-python
elastic-transport-python copied to clipboard
`retry_on_status` setting does not work as expected with requests that should not be retried immediately
Steps to reproduce:
Happens for me on clusters of 8.12 and 8.13 with clients of same versions, I assume it happens in earlier clusters as well.
- Have a cluster that's rather small (I used 2GB RAM Elasticsearch in Elastic Cloud)
- Have a script that bombs this cluster with
bulkrequests that will eventually lead to this cluster returning 429 back. - Have another script that just does
searchon this cluster with Elasticsearch client that is initialised with defaultretry_on_status- presumably, it should retry 429s.
What happens is - client in 3. actually retries 429, but fails almost immediately as it does not try to sleep with any sort of backoff strategy, so it retries a couple times in a row within a second and give up.
Expected behaviour Client allows to retry with a backoff strategy. Additionally, if the client is closed, would be great if the pending retry immediately wakes up and exits without retrying (see https://github.com/elastic/elasticsearch-py/issues/2484)