Configurable Retry Strategy

[arupadhy]

💬 Questions and Help

While using this library, i realised there isn't any way to have configurable retry strategy or options to choose from. Specifically retry with some backoff factor that increases exponentially on failures.

Is there an alternative to achieve that via this lib?

Please note that this issue tracker is not a help forum and this issue may be closed.

It's not uncommon that somebody already opened an issue or in the best case it's already fixed but not merged. That's the reason why you should search at first before submitting a new one.

[delvedor]

Hello! At the moment is not possible to configure it unless you extend the Transport class and override its internals.
This could be a useful feature, I'll invest some time to study how it can be done and exposed to the user.

[delvedor]

Hello again! I’ve talked about this internally and we think that having a retry mechanism inside the client itself could be harmful and lead to some misunderstanding on how the API behaves.

Currently, the client has a fast failover mechanism, meaning that as soon that an API call fails, we decide if we should retry it or not based on what error we got. This is valid for any API call, for example, we never retry on 400 or 429, but we do retry on a connection fault or a 504.

The philosophy of the clients is to fail fast when something does not work as expected, and having a retry with exponential backoff mechanism directly hooked into the client other than breaking this philosophy could cause unwanted side effects, for instance, it might make no sense to retry a failing search, while it does for a cluster update.

A feasible solution for offering a nice way to support retries with exponential backoff would be to provide a helper that does this work for you, and it’s smart enough to understand if it makes sense to retry an API call or not.
A pseudo-javascript example:

const response = await client.helpers.retry(
  client.index, // api call you want to retry
  { requestParams }, // parameter for the call
  { requestOptions }, // custom request configuration
  { backoff: '2x', ignore: [500] } // retry configuration
)

[loretoparisi]

Has this feature been implemented?

[github-actions]

This issue is stale because it has been open 90 days with no activity. Remove the stale label, or leave a comment, or this will be closed in 14 days.

[rudolf]

As comparison using DynamoDB through the AWS SDK's comes with built-in retry mechanism with jittered exponential backoff https://docs.aws.amazon.com/sdkref/latest/guide/feature-retry-behavior.html

If you want to have a robust integration with a service that can apply throttling you need to implement retries. If every developer implements this themselves the quality of the retry mechanism will likely be poorer (e.g. no exponential back-off, no jitter).

[JoshMock]

Retry backoff with jitter was added as the default retry strategy in the @elastic/transport v8.6.0 (elastic/elastic-transport-js#101). It is possible to override the behavior by instantiating Transport with a custom function.

Admittedly, this behavior could be documented better, but it is mentioned here, including the signature and return type of the function.