Aws::Plugins::RetryErrors is retrying all errors even program specific errors.

[ph]

I've stepped on this while migrating to the v2 version of library (which is excellent btw) and I am not sure if it is the expected behavior of the retryerrors plugin.

Lets say we are running the SQS's QueuePoller in some threads and we use Thread#raise to stop them (Which is a bad pratice, we are getting rid of it)

inputs.each { |t| t.raise(LogStash::ShutdownSignal) }

In some cases if we are in the AWS codes, the retry code will catches this error and will retry and succeed, the error will never be raised back upstream. By inspecting the code we see that the error is wrapped and the #retryable? method will return true because of the http_status_code=0.

=> #<Aws::Plugins::RetryErrors::ErrorInspector:0x4ed7db29 @error=#<LogStash::ShutdownSignal: LogStash::ShutdownSignal>, @http_status_code=0, @name="LogStash::ShutdownSignal">

Should the retryable library ignore errors outside of Aws::Errors::ServiceError and specific http code?

[trevorrowe]

I did some digging into this. I don't believe the SDK should actually retry these errors. The Net HTTP handler already rescues known networking errors and decorates them in a way that trigger retries. This means only runtime errors and signal errors should be causing a 0 status code.

[trevorrowe]

Thanks for reporting the issue!

[ph]

@trevorrowe Thanks!