Skip retries for known failures

[indirect]

When making a network request, Net::HTTP::NotFound is never going to spontaneously start working on retry. Likewise TooManyRedirects, Forbidden, and probably others I'm not thinking of. We should not retry those responses.

[RochesterinNYC]

Any other exception classes to not retry on? There are a few Error types that seem applicable that aren't currently on the list, but they were added in relatively recent versions of the Ruby core lib so adding them to the list throws errors in the Travis builds for the earlier rubies that wouldn't have those Error classes in core lib yet.

[segiddins]

@RochesterinNYC we can always do ERRORS << NewExceptionClass if defined?(NewExceptionClass)

[mattbrictson]

Actually I ran into this today, I think due to the Rubygems move to Fastly.

For a period of time today gem downloads were sporadically failing with 404s. E.g.:

Not Found 404 (https://rubygems.global.ssl.fastly.net/gems/devise-3.5.3.gem)

Despite my retry setting, Bundler did not retry, due to the recently merged #4155.

I think this is evidence that "once a 404, always a 404" is not necessarily the case. Also, maybe Bundler should retry on 502 as well?

[indirect]

@mattbrictson if Fastly returns a 404 due to a system error, there is no reason to think that retrying will succeed, though. You'll have to wait until the system issue is resolved before it'll work, and mechanically trying over and over doesn't seem like a good way to check for that...

[mattbrictson]

if Fastly returns a 404 due to a system error, there is no reason to think that retrying will succeed

@indirect Fair enough. But isn't that true of all HTTP errors other than perhaps a 503 with an accompanying Retry-After header?

I'm not intending to be pedantic; I am just curious to know what use case --retry is intended to solve. Is it mostly for network issues (socket timeout, connection dropped, etc.) and not for HTTP errors?

[segiddins]

@mattbrictson I believe that is the main intention, yes.

[indirect]

@mattbrictson yes, it's primarily for network errors and server 500 errors that might be transient or limited to a single backend.

[mattbrictson]

OK, makes sense. Thanks.

[indirect]

closing this as fixed by @RochesterinNYC's recent work