Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Connection reset errors are not retryable #2908

Closed
AVoskoboinikov opened this issue Oct 24, 2019 · 2 comments
Closed

Connection reset errors are not retryable #2908

AVoskoboinikov opened this issue Oct 24, 2019 · 2 comments
Labels
guidance Question that needs advice or information.

Comments

@AVoskoboinikov
Copy link

Version of AWS SDK for Go?

v1.23.21

Version of Go (go version)?

go1.12.9 darwin/amd64

What issue did you see?

This ticket is more a question to AWS folks rather than a bug/issue.

Check this file: aws-sdk-go/aws/request/connection_reset_error.go
Current content is

func isErrConnectionReset(err error) bool {
	if strings.Contains(err.Error(), "read: connection reset") {
		return false
	}

	if strings.Contains(err.Error(), "connection reset") ||
		strings.Contains(err.Error(), "broken pipe") {
		return true
	}

	return false
}

I understand that the the error read: connection reset was deliberately made as a not retryable for internal retry mechanism. Could you, please, explain why this error is not retryable? Is it safe to implement our own custom retry mechanism just for this particular error?

Our motivation to retry this kind of errors is related to this issue.

Steps to reproduce

Nothing to reproduce

@diehlaws diehlaws self-assigned this Nov 22, 2019
@diehlaws diehlaws added the guidance Question that needs advice or information. label Nov 22, 2019
@diehlaws
Copy link
Contributor

Hi @AVoskoboinikov, thanks for reaching out and I do apologize for the long delay in response on this. You are correct in that connection reset errors are deliberately not retryable in the default retryer's logic. As @skmcgrail mentions in #2926 this behavior was introduced as part of commit c3d2710 because the SDK cannot determine the state of the API call on which the connection was reset, and we do not want to have the SDK blindly re-issue non-idempotent requests that were received and processed by the service before the connection was reset.

If you are confident that the requests you are issuing with the SDK are idempotent (or don't mind if non-idempotent requests upon which the connection is reset are duplicated from the service end) you can implement a custom retryer that does retry these errors.

@AVoskoboinikov
Copy link
Author

Thanks @diehlaws for the explanation. I am going to close this ticket now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
guidance Question that needs advice or information.
Projects
None yet
Development

No branches or pull requests

2 participants