Is it possible to define different retry behavior per HTTP method?

[kobik]

What would you like to discuss?

I wonder if it's possible for the same got instance created by extend to define a different retry behavior for idempotent and non-idempotent method, i.e different retry behavior of GET vs POST.

I know that I create two got instances, but i still wonder wether it's possible to achieve this behavior using one instance.

// for GET, PUT, OPTIONS, HEAD and etc
const idempotentRequestor = got.extend({
  retry: 2, // use got defaults
});

// for POST
const nonIdempotentRequestor = got.extend({
  retry: {
    limit: 2,
    methods: ['POST'],
    errorCodes: [
      'ECONNRESET',
      'EADDRINUSE',
      'ECONNREFUSED',
      'EPIPE',
      'ENOTFOUND',
      'ENETUNREACH',
      'EAI_AGAIN',
    ],
  },
});

If it's not currently an option, is it possible to add this feature? I can also prepare a PR.

I'd like to avoid maintaining two instances which could cause a confusion and bugs, as devs could use the wrong instance.

Checklist

• I have read the documentation.

Thanks for the hard work!

[Giotino]

You can use calculateDelay (https://github.com/sindresorhus/got#retry)

const postErrorCodes = [
  'ECONNRESET',
  'EADDRINUSE',
  'ECONNREFUSED',
  'EPIPE',
  'ENOTFOUND',
  'ENETUNREACH',
  'EAI_AGAIN'
];

const instance = got.extend({
  retry: {
    // return 0 means no retry
    calculateDelay: ({error}) => {
      if (error.options.method === 'POST')
        return postErrorCodes.includes(error.code!) ? 1 : 0;

      retry 1;
    },
    limit: 2
  },
});

[kobik]

Hi @Giotino , thanks for your answer.

According to the docs the retry delay in ms should be returned from calculateDelay.

The way I found getting it without calculating it by myself and taking all considerations such as Retry-After, attemptsCount and so on, is by passing all methods, statusCodes and errorCodes to their corresponding retry props in order to retry on all cases by default, take the actual decision inside calculateDelay as you suggested and return the computedValue.

as a suggestion if there was a simple shouldRetryFunction to return this decision, a simple boolean option to always retry or ability to pass an array of RequiredRetryOptions to retry prop that would have been great.

If there is no intention to do so, although it's less than optimal I can live with what the current solution and this issue can be closed.

Thanks!

[Giotino]

I don't think there's any intention to implement something like that because whats you're trying to achieve can be done easily. My previous example wasn't accounting for the retry delay that a request should have (in some cases), take a look at this new example.

(this is probably what you were describing in your comment)

const postErrorCodes = [
  'ECONNRESET',
  'EADDRINUSE',
  'ECONNREFUSED',
  'EPIPE',
  'ENOTFOUND',
  'ENETUNREACH',
  'EAI_AGAIN'
];

const instance = got.extend({
  retry: {
    // return 0 means no retry
    calculateDelay: ({error, computedValue}) => {
      if (error.options.method === 'POST')
        return postErrorCodes.includes(error.code!) ? computedValue : 0;

      retry computedValue;
    },
    limit: 2
  },
});

In this case you have a function that is doing the same as the shouldRetryFunction I think you're imagining.
shouldRetryFunction is going to return true instead of computedValue, anything else is going to be identical.

[kobik]

The first thing I did was actually what you suggested here, but now I get why it didn't work for me.

computedValue would be a non-zero value only if the custom errorCodes and statusCodes overlaps with their corresponding default values.

In my test I tried it with 404 status code which isn't part of the default statusCodes according to the docs.

OK, I think I know how handle it better now.

Thanks