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

I wonder why read: connection reset shouldn't retry #4793

Closed
Leavrth opened this issue Apr 11, 2023 · 2 comments
Closed

I wonder why read: connection reset shouldn't retry #4793

Leavrth opened this issue Apr 11, 2023 · 2 comments
Assignees
Labels
bug This issue is a bug. p3 This is a minor priority issue

Comments

@Leavrth
Copy link

Leavrth commented Apr 11, 2023

Describe the bug

I see this PR modify the retry logic,

func isErrConnectionReset(err error) bool {
if strings.Contains(err.Error(), "read: connection reset") {
return false
}
if strings.Contains(err.Error(), "use of closed network connection") ||
strings.Contains(err.Error(), "connection reset") ||
strings.Contains(err.Error(), "broken pipe") {
return true
}
return false
}

Expected Behavior

However, I got the error RequestError: send request failed\ncaused by: Put "xxxx": read tcp 10.212.83.32:36378->10.101.100.127:9000: read: connection reset by peer

Current Behavior

It seems not retryable.

Reproduction Steps

It's about the connection error, and only calls the PutObjectWithContext API.

Possible Solution

I want to use the custom retryer to make the error retryable. So I want to know what the risk is of retrying this error.

Additional Information/Context

No response

SDK version used

1.44.48

Environment details (Version of Go (go version)? OS name and version, etc.)

1.20.1 centos 7

@Leavrth Leavrth added bug This issue is a bug. needs-triage This issue or PR still needs to be triaged. labels Apr 11, 2023
@jmklix jmklix self-assigned this Apr 18, 2023
@jmklix jmklix added p3 This is a minor priority issue and removed needs-triage This issue or PR still needs to be triaged. labels Apr 21, 2023
@jmklix
Copy link
Member

jmklix commented Apr 21, 2023

This has been discussed a few times previously and this is the answer:

The logic behind this change is that the SDK is not able to sufficiently determine the state of an API request after successfully writing the request to the transport layer, but then failing to read the corresponding response due to a connection reset occurring. This is due to the fact that the SDK has no knowledge about whether the given operation is idempotent or whether it would be safe to retry.

This is open as a feature request, but I'm not sure when it might be completed.

@jmklix jmklix closed this as completed Apr 21, 2023
@github-actions
Copy link

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug This issue is a bug. p3 This is a minor priority issue
Projects
None yet
Development

No branches or pull requests

2 participants