elastic-transport-python icon indicating copy to clipboard operation
elastic-transport-python copied to clipboard

`retry_on_status` setting does not work as expected with requests that should not be retried immediately

Open artem-shelkovnikov opened this issue 1 year ago • 3 comments

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.

  1. Have a cluster that's rather small (I used 2GB RAM Elasticsearch in Elastic Cloud)
  2. Have a script that bombs this cluster with bulk requests that will eventually lead to this cluster returning 429 back.
  3. Have another script that just does search on this cluster with Elasticsearch client that is initialised with default retry_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)

artem-shelkovnikov avatar Mar 22 '24 14:03 artem-shelkovnikov