Retry feature about got HOT 4 CLOSED

@sindresorhus I'm kind of against retry functionality in got, yet it come in handy from time to time. Here's why:

• retry will add quite a few options - retryCount, retryDelay and etc...
• Streams will not support this without buffering and be useless by default (if retry will be enabled by default)
• Same as redirect, retry should be enabled only for GET and HEAD, right? Should it be configurable?

So it is kind of heavy feature and I believe, that retry should be added consciously by developer.

const retry = require('retry');
const got = require('got');

let result = await retry(() => { return got('google.com'); });

from got.

@floatdrop

• Yes, more options would be added, but it is not a bad thing, is it?
• True, but we can mention this behavior explicitly in the docs
• retry would be enabled for all requests, because it would retry requests only on network failures, like EAI_AGAIN, ETIMEDOUT, etc.

So, to sum up, the implementation would be pretty lightweight, but the benefits are obvious. The only point is to deal with network failures, not response failures (interpreting status code, etc).

from got.

I didn't mean we should implement all the retry options. I just want a option-less sane default.

The benefit of including it in core is that all consumers benefit without doing any extra work, or more importantly without having to know it's needed in the first place. Most wouldn't even be aware they should be using retry with got. If we decide to recommend it in the readme instead, all got consumers will have to do the same with their readmes, etc...

from got.

The only point is to deal with network failures, not response failures

@vdemedes then I misunderstood issue a little - in this case streams still can be in game. Cool 🌴

from got.