vercel / fetch-retry

Wrapper around `fetch` with sensible retrying defaults

fetch-retry

This repo has been archived and the source has been moved to vercel/fetch monorepo

A layer on top of fetch (via node-fetch) with sensible defaults for retrying to prevent common errors.

How to use

fetch-retry is a drop-in replacement for fetch:

const fetch = require('@vercel/fetch-retry')(require('node-fetch'))

module.exports = async () => {
  const res = await fetch('http://localhost:3000')
  console.log(res.status);
}

Make sure to yarn add @vercel/fetch-retry in your main package.

Note that you can pass retry options to using opts.retry. We also provide a opts.onRetry and opts.retry.maxRetryAfter options.

opts.onRetry is a customized version of opts.retry.onRetry and passes not only the error object in each retry but also the current opts object.

opts.retry.maxRetryAfter is the max wait time according to the Retry-After header. If it exceeds the option value, stop retrying and returns the error response. It defaults to 20.

Rationale

Some errors are very common in production (like the underlying Socket yielding ECONNRESET), and can easily and instantly be remediated by retrying.

The default behavior of fetch-retry is to attempt retries 10, 60 360, 2160 and 12960 milliseconds (a total of 5 retries) after a network error, 429 or 5xx error occur.

The idea is to provide a sensible default: most applications should continue to perform correctly with a worst case scenario of a given request having an additional 15550ms overhead.

On the other hand, most applications that use fetch-retry instead of vanilla fetch should see lower rates of common errors and fewer 'glitches' in production.

Tests

To run rests, execute

npm test

fetch-retry's Issues

Fetch-Mock or Jest-Fetch-Mock does not work with the latest fetch-retry

When there are no retries, it works fine. On retry, it times out and never makes the fetch call again.

bug: opts.retry should not be passed to fetch

Hi there 👋 ,

According to the docs, you may add opts.retry to fetch like this:

const opts = { retry: {
  retries: 3,
}};
await fetch('url', opts)

But this actually ends up passing the retry directly to fetch as well, even if this is not a valid option in fetch. It is nice that you can override the retry options per fetch invocation, but it would be good if this was not passed to fetch. This causes errors in combination with the nock test tool, as it will not be able to intercept the call anymore.

Suggestion Solution:
fetch-retry should not pass retry options to fetch. This can be done by removing opts.retry before passing it to fetch.

Add jitter option to retry

If we use the same retry values, everywhere we're setting ourselves up for a thundering herd. What happens is that requests tend to line up with each other on the retry intervals over time. So adding jitter will help break up the cycles. Here's a great article from AWS with some data https://aws.amazon.com/blogs/architecture/exponential-backoff-and-jitter/

Do not assumme peer dependency. Export a function that takes in the `fetch` to decorate

Move to:

const fetch = require('fetch-retry')(require('node-fetch'))

Does it work in the browser replacing the fetch api?

Can i add this to my client side application ?Can i use it to replace fetch?
I dont need node-fetch in as the browser already has the built in fetch.

Publish new version

It'd be great to use the changes introduced by #32 👍

ENHANCEMENT: Some way to add different url sources?

I am integrating payments for a site and I need to fetch the dollar price for ARS, I need this to make the payment. I am fetching this from a national bank's API but it sometimes fails so I made my own fetch retry, and then started researching for it. I am used to making bots so I need a fault-tolerant fetch, a fetch that will always give you what you need, maybe by providing different source APIs, it would retry or switch until it gets a useful result. I am still trying to understand your code, it seems you are using some knowledge on how fetch retries by itself? I can't see the code looping or increasing attempts.

Add license

Needs license property in package.json and a license file.

Don't retry upon *any* 5xx status code

501 for example means Not Implemented. ie: not worth retrying.

500
502
503
504

make sense instead.

Action required: Greenkeeper could not be activated 🚨

🚨 You need to enable Continuous Integration on all branches of this repository. 🚨

To enable Greenkeeper, you need to make sure that a commit status is reported on all branches. This is required by Greenkeeper because it uses your CI build statuses to figure out when to notify you about breaking changes.

Since we didn’t receive a CI status on the greenkeeper/initial branch, it’s possible that you don’t have CI set up yet. We recommend using Travis CI, but Greenkeeper will work with every other CI service as well.

If you have already set up a CI for this repository, you might need to check how it’s configured. Make sure it is set to run on all new branches. If you don’t want it to run on absolutely every branch, you can whitelist branches starting with greenkeeper/.

Once you have installed and configured CI on this repository correctly, you’ll need to re-trigger Greenkeeper’s initial pull request. To do this, please delete the greenkeeper/initial branch in this repository, and then remove and re-add this repository to the Greenkeeper App’s white list on Github. You'll find this list on your repo or organization’s settings page, under Installed GitHub Apps.