retry vs p-retry vs promise-retry vs async-retry vs retry-axios vs promise-poller
JavaScript Retry Libraries Comparison
1 Year
retryp-retrypromise-retryasync-retryretry-axiospromise-pollerSimilar Packages:
What's JavaScript Retry Libraries?

These libraries provide mechanisms to retry asynchronous operations that may fail due to transient issues, such as network errors or temporary unavailability of services. They help improve the resilience of applications by automatically handling retries with customizable strategies, such as exponential backoff, delay intervals, and maximum retry limits. This is particularly useful in scenarios like API calls, where failures can occur sporadically, and simply retrying the operation can lead to successful outcomes without requiring manual intervention.

Package Weekly Downloads Trend
Github Stars Ranking
Stat Detail
Package
Downloads
Stars
Size
Issues
Publish
License
retry41,194,1041,244-194 years agoMIT
p-retry16,792,37083313.2 kB174 months agoMIT
promise-retry15,738,445315-115 years agoMIT
async-retry10,565,8911,864-304 years agoMIT
retry-axios912,45549536.4 kB34a year agoApache-2.0
promise-poller23,052117-85 years agoMIT
Feature Comparison: retry vs p-retry vs promise-retry vs async-retry vs retry-axios vs promise-poller

Retry Strategy Customization

  • retry:

    retry offers a simple API for defining retry strategies, including the ability to set delays, maximum attempts, and specific error types to retry on, making it versatile for both sync and async functions.

  • p-retry:

    p-retry provides a straightforward API for retrying promises with default exponential backoff, but it also allows for customization of the number of retries and delay intervals, making it easy to adapt to various scenarios.

  • promise-retry:

    promise-retry supports various retry strategies, including exponential backoff and custom delay functions, enabling developers to tailor the retry behavior to their specific needs and error handling requirements.

  • async-retry:

    async-retry allows for extensive customization of retry strategies, including configurable delays, maximum retries, and the ability to define custom retry conditions based on the error type or response status.

  • retry-axios:

    retry-axios integrates retry logic directly into Axios requests, allowing users to specify retry conditions, such as HTTP status codes, and customize the retry delay, making it ideal for handling API request failures.

  • promise-poller:

    promise-poller focuses on polling rather than traditional retries, allowing users to define the polling interval and maximum duration for checking the promise's resolution, providing flexibility for long-running operations.

Ease of Use

  • retry:

    retry has a simple API that is easy to understand, making it accessible for developers who want to add retry logic to their functions without a steep learning curve.

  • p-retry:

    p-retry is extremely easy to use, providing a minimalistic interface that allows developers to retry promises with just a few lines of code, making it ideal for quick implementations.

  • promise-retry:

    promise-retry offers a balance of ease of use and configurability, allowing developers to implement retries with minimal code while still providing options for advanced configurations.

  • async-retry:

    async-retry is designed to be user-friendly, with a clear API that makes it easy to implement retries in asynchronous functions without requiring extensive setup or configuration.

  • retry-axios:

    retry-axios is easy to integrate into existing Axios requests, allowing developers to add retry logic with minimal changes to their existing codebase.

  • promise-poller:

    promise-poller is straightforward for polling scenarios, providing a simple method to repeatedly check a promise until it resolves or times out, making it easy to implement polling logic.

Integration

  • retry:

    retry is a general-purpose library that can be applied to any function, whether synchronous or asynchronous, making it highly adaptable for different scenarios.

  • p-retry:

    p-retry is a standalone library that can be used with any promise-based function, providing flexibility for integration into different projects without dependencies on specific frameworks.

  • promise-retry:

    promise-retry is also standalone and can be integrated into any promise-returning function, offering flexibility for developers to use it in various contexts without restrictions.

  • async-retry:

    async-retry can be used independently in any asynchronous context, making it versatile for various applications, but it does not have built-in integration with specific libraries.

  • retry-axios:

    retry-axios is specifically designed for use with Axios, providing seamless integration for retrying HTTP requests, making it the go-to choice for developers using Axios for API calls.

  • promise-poller:

    promise-poller is independent and can be used in any JavaScript environment, making it suitable for polling operations across different applications and use cases.

Error Handling

  • retry:

    retry provides robust error handling features, allowing users to specify which errors to retry on and how to handle failures, making it suitable for various error scenarios.

  • p-retry:

    p-retry provides basic error handling capabilities, allowing users to specify which errors should be retried, but it may not offer as much flexibility as other libraries for complex error scenarios.

  • promise-retry:

    promise-retry offers advanced error handling options, allowing developers to define custom logic for handling errors and determining whether to retry based on specific conditions.

  • async-retry:

    async-retry allows developers to define custom error handling logic, enabling them to specify which errors should trigger a retry and how to handle failures after all retries have been exhausted.

  • retry-axios:

    retry-axios integrates error handling directly into Axios requests, allowing developers to specify which HTTP status codes should trigger a retry, making it effective for managing API call failures.

  • promise-poller:

    promise-poller focuses on polling and does not inherently provide error handling for the promise being checked, leaving it up to the user to manage errors during polling operations.

Performance

  • retry:

    retry is designed to be performant, allowing for retries with minimal impact on application responsiveness, making it suitable for both synchronous and asynchronous functions.

  • p-retry:

    p-retry is lightweight and efficient, providing a minimal performance impact when retrying promises, making it ideal for scenarios where performance is critical.

  • promise-retry:

    promise-retry is efficient in handling retries, especially with exponential backoff strategies, ensuring that retries do not overwhelm the system or service being called.

  • async-retry:

    async-retry is optimized for performance, allowing developers to implement retries without significant overhead, making it suitable for high-frequency asynchronous operations.

  • retry-axios:

    retry-axios is designed to handle retries efficiently within Axios, ensuring that network requests are retried without causing significant delays in the application.

  • promise-poller:

    promise-poller is designed for polling operations, and its performance depends on the polling interval set by the user, allowing for efficient checks without excessive resource usage.

How to Choose: retry vs p-retry vs promise-retry vs async-retry vs retry-axios vs promise-poller
  • retry:

    Choose retry if you want a general-purpose retry mechanism that can work with both synchronous and asynchronous functions. It offers a variety of options for configuring retries, including delays and maximum attempts, making it versatile for different use cases.

  • p-retry:

    Select p-retry if you prefer a promise-based approach with a focus on simplicity and ease of use. It provides a clean API for retrying promises and is ideal for use cases where you want to retry a single promise-returning function with minimal configuration.

  • promise-retry:

    Use promise-retry if you require a more robust solution that allows for advanced configurations, such as custom retry strategies and error handling. It is suitable for complex scenarios where you need more control over the retry logic and behavior.

  • async-retry:

    Choose async-retry if you need a simple and flexible way to retry asynchronous functions with support for customizable retry strategies and delays. It is particularly useful for scenarios where you want to handle retries in a straightforward manner without additional complexity.

  • retry-axios:

    Select retry-axios if you are specifically working with Axios for HTTP requests and want to implement retry logic directly within your API calls. This library integrates seamlessly with Axios, allowing you to specify retry behavior for network requests.

  • promise-poller:

    Opt for promise-poller if you need to repeatedly check the status of a promise until it resolves successfully or a timeout occurs. This is particularly useful for polling scenarios, such as waiting for a resource to become available or for a specific condition to be met.

README for retry

Build Status codecov

retry

Abstraction for exponential and custom retry strategies for failed operations.

Installation

npm install retry

Current Status

This module has been tested and is ready to be used.

Tutorial

The example below will retry a potentially failing dns.resolve operation 10 times using an exponential backoff strategy. With the default settings, this means the last attempt is made after 17 minutes and 3 seconds.

var dns = require('dns');
var retry = require('retry');

function faultTolerantResolve(address, cb) {
  var operation = retry.operation();

  operation.attempt(function(currentAttempt) {
    dns.resolve(address, function(err, addresses) {
      if (operation.retry(err)) {
        return;
      }

      cb(err ? operation.mainError() : null, addresses);
    });
  });
}

faultTolerantResolve('nodejs.org', function(err, addresses) {
  console.log(err, addresses);
});

Of course you can also configure the factors that go into the exponential backoff. See the API documentation below for all available settings. currentAttempt is an int representing the number of attempts so far.

var operation = retry.operation({
  retries: 5,
  factor: 3,
  minTimeout: 1 * 1000,
  maxTimeout: 60 * 1000,
  randomize: true,
});

API

retry.operation([options])

Creates a new RetryOperation object. options is the same as retry.timeouts()'s options, with three additions:

  • forever: Whether to retry forever, defaults to false.
  • unref: Whether to unref the setTimeout's, defaults to false.
  • maxRetryTime: The maximum time (in milliseconds) that the retried operation is allowed to run. Default is Infinity.

retry.timeouts([options])

Returns an array of timeouts. All time options and return values are in milliseconds. If options is an array, a copy of that array is returned.

options is a JS object that can contain any of the following keys:

  • retries: The maximum amount of times to retry the operation. Default is 10. Seting this to 1 means do it once, then retry it once.
  • factor: The exponential factor to use. Default is 2.
  • minTimeout: The number of milliseconds before starting the first retry. Default is 1000.
  • maxTimeout: The maximum number of milliseconds between two retries. Default is Infinity.
  • randomize: Randomizes the timeouts by multiplying with a factor between 1 to 2. Default is false.

The formula used to calculate the individual timeouts is:

Math.min(random * minTimeout * Math.pow(factor, attempt), maxTimeout)

Have a look at this article for a better explanation of approach.

If you want to tune your factor / times settings to attempt the last retry after a certain amount of time, you can use wolfram alpha. For example in order to tune for 10 attempts in 5 minutes, you can use this equation:

screenshot

Explaining the various values from left to right:

  • k = 0 ... 9: The retries value (10)
  • 1000: The minTimeout value in ms (1000)
  • x^k: No need to change this, x will be your resulting factor
  • 5 * 60 * 1000: The desired total amount of time for retrying in ms (5 minutes)

To make this a little easier for you, use wolfram alpha to do the calculations:

http://www.wolframalpha.com/input/?i=Sum%5B1000*x^k%2C+{k%2C+0%2C+9}%5D+%3D+5+*+60+*+1000

retry.createTimeout(attempt, opts)

Returns a new timeout (integer in milliseconds) based on the given parameters.

attempt is an integer representing for which retry the timeout should be calculated. If your retry operation was executed 4 times you had one attempt and 3 retries. If you then want to calculate a new timeout, you should set attempt to 4 (attempts are zero-indexed).

opts can include factor, minTimeout, randomize (boolean) and maxTimeout. They are documented above.

retry.createTimeout() is used internally by retry.timeouts() and is public for you to be able to create your own timeouts for reinserting an item, see issue #13.

retry.wrap(obj, [options], [methodNames])

Wrap all functions of the obj with retry. Optionally you can pass operation options and an array of method names which need to be wrapped.

retry.wrap(obj)

retry.wrap(obj, ['method1', 'method2'])

retry.wrap(obj, {retries: 3})

retry.wrap(obj, {retries: 3}, ['method1', 'method2'])

The options object can take any options that the usual call to retry.operation can take.

new RetryOperation(timeouts, [options])

Creates a new RetryOperation where timeouts is an array where each value is a timeout given in milliseconds.

Available options:

  • forever: Whether to retry forever, defaults to false.
  • unref: Wether to unref the setTimeout's, defaults to false.

If forever is true, the following changes happen:

  • RetryOperation.errors() will only output an array of one item: the last error.
  • RetryOperation will repeatedly use the timeouts array. Once all of its timeouts have been used up, it restarts with the first timeout, then uses the second and so on.

retryOperation.errors()

Returns an array of all errors that have been passed to retryOperation.retry() so far. The returning array has the errors ordered chronologically based on when they were passed to retryOperation.retry(), which means the first passed error is at index zero and the last is at the last index.

retryOperation.mainError()

A reference to the error object that occured most frequently. Errors are compared using the error.message property.

If multiple error messages occured the same amount of time, the last error object with that message is returned.

If no errors occured so far, the value is null.

retryOperation.attempt(fn, timeoutOps)

Defines the function fn that is to be retried and executes it for the first time right away. The fn function can receive an optional currentAttempt callback that represents the number of attempts to execute fn so far.

Optionally defines timeoutOps which is an object having a property timeout in miliseconds and a property cb callback function. Whenever your retry operation takes longer than timeout to execute, the timeout callback function cb is called.

retryOperation.try(fn)

This is an alias for retryOperation.attempt(fn). This is deprecated. Please use retryOperation.attempt(fn) instead.

retryOperation.start(fn)

This is an alias for retryOperation.attempt(fn). This is deprecated. Please use retryOperation.attempt(fn) instead.

retryOperation.retry(error)

Returns false when no error value is given, or the maximum amount of retries has been reached.

Otherwise it returns true, and retries the operation after the timeout for the current attempt number.

retryOperation.stop()

Allows you to stop the operation being retried. Useful for aborting the operation on a fatal error etc.

retryOperation.reset()

Resets the internal state of the operation object, so that you can call attempt() again as if this was a new operation object.

retryOperation.attempts()

Returns an int representing the number of attempts it took to call fn before it was successful.

License

retry is licensed under the MIT license.

Changelog

0.10.0 Adding stop functionality, thanks to @maxnachlinger.

0.9.0 Adding unref functionality, thanks to @satazor.

0.8.0 Implementing retry.wrap.

0.7.0 Some bug fixes and made retry.createTimeout() public. Fixed issues #10, #12, and #13.

0.6.0 Introduced optional timeOps parameter for the attempt() function which is an object having a property timeout in milliseconds and a property cb callback function. Whenever your retry operation takes longer than timeout to execute, the timeout callback function cb is called.

0.5.0 Some minor refactoring.

0.4.0 Changed retryOperation.try() to retryOperation.attempt(). Deprecated the aliases start() and try() for it.

0.3.0 Added retryOperation.start() which is an alias for retryOperation.try().

0.2.0 Added attempts() function and parameter to retryOperation.try() representing the number of attempts it took to call fn().