-
Notifications
You must be signed in to change notification settings - Fork 2.4k
ClusterClient does not retry TxPipeline on EOF when reading response. #2954
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
Comments
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
There are occasions when a connection handling a TxPipeline gets closed unexpectedly (maybe because the remote server shut down). Despite the pool's attempts to discard bad idle connections, this validation is not 100% reliable (since the connection can be closed after it's returned from the pool and while it's being used). In my experience this results in an EOF error not while writing the commands on the connection but only once attempting to read the result.
Expected Behavior
When using a
ClusterClient.TxPipeline
, pipelines should be retried when an EOF (or another retryable error) is returned while reading the pipeline responses.Current Behavior
ClusterClient.TxPipeline
will retry if an EOF is observed while writing the commands to the connection:go-redis/osscluster.go
Lines 1497 to 1505 in f3fe611
However, when reading the response from the connection in
go-redis/osscluster.go
Lines 1508 to 1525 in f3fe611
go-redis/osscluster.go
Lines 1537 to 1547 in f3fe611
In particular, there may be an EOF in these circumstances:
MULTI
:go-redis/osscluster.go
Line 1537 in f3fe611
go-redis/osscluster.go
Line 1542 in f3fe611
EXEC
:go-redis/osscluster.go
Line 1550 in f3fe611
go-redis/osscluster.go
Line 1525 in f3fe611
However, only the last case handles retryable errors and updates
failedCmds
to trigger the retry machinery:go-redis/osscluster.go
Lines 1354 to 1360 in f3fe611
Possible Solution
Update
txPipelineReadQueued
and the error handling for it inprocessTxPipelineNodeConn
to account for retryable errors and update thefailedCmds
parameter appropriately.Steps to Reproduce
Let me know if there's appetite for addressing this and I can work on a repro.
Context (Environment)
Redis Server: 7.1
go-redis client: 9.5.1
Detailed Description
Possible Implementation
The text was updated successfully, but these errors were encountered: