Connection regression since 7.1.0

[carl-mastrangelo]

I was trying to update from 7.1.0 to 7.4.0 and noticed that our unit tests stopped passing with the new version. Somewhere in between the two versions, connecting to a Redis server started taking a very long time, to the point that the tests timed out. Looking through what changed in a debugger, it appears that some connection retry and backoff was added.

Our code attempts to connect to a redis server, and if unavailable, logs an exception and continues on. The unit tests don't start a redis server and thus will never successfully connect. However, since 7.4.0, it appears there is now a lot more retrying and sleeping, which is not desirable. We also go out of our way to try and bound the amount of time spent connecting:

conn = Redis(port=redis_port(), socket_timeout=2.0, socket_connect_timeout=2.0)

I feel like this behavior is a regression, since the behavior was predictable and fast.

[nadiatazi262-tech]

Thanks for the report — this does sound like a behavior change on our side. The added retry/backoff could be causing the delay you’re seeing. We’ll take a closer look to confirm and see if we can make this more predictable

…

On Mon, Apr 6, 2026, 2:22 PM Carl Mastrangelo ***@***.***> wrote: *carl-mastrangelo* created an issue (redis/redis-py#4026) <#4026> I was trying to update from 7.1.0 to 7.4.0 and noticed that our unit tests stopped passing with the new version. Somewhere in between the two versions, connecting to a Redis server started taking a very long time, to the point that the tests timed out. Looking through what changed in a debugger, it appears that some connection retry and backoff was added. Our code attempts to connect to a redis server, and if unavailable, logs an exception and continues on. The unit tests don't start a redis server and thus will never successfully connect. However, since 7.4.0, it appears there is now a lot more retrying and sleeping, which is not desirable. We also go out of our way to try and bound the amount of time spent connecting: conn = Redis(port=redis_port(), socket_timeout=2.0, socket_connect_timeout=2.0) I feel like this behavior is a regression, since the behavior was predictable and fast. — Reply to this email directly, view it on GitHub <#4026>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/B7HY73Y27YFAWAPYFPO3YFT4UP7WLAVCNFSM6AAAAACXOP3SJSVHI2DSMVQWIX3LMV43ASLTON2WKOZUGIYTGNRRGY2TCNA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[petyaslavova]

Hey @carl-mastrangelo, thank you for reporting this and for the detailed description of your use case!

The behavior you're observing is actually an intentional change rather than a regression. Previously, the client lacked a retry mechanism for cases when handshake commands (like AUTH, SELECT, CLIENT SETINFO, etc.) failed during connection establishment. This was a bug — when retries were enabled, it was inconsistent that the connection handshake phase wouldn't participate in the retry flow. The fix ensures that the entire command execution pipeline, including the initial connection handshake, has retry capability when retries are configured.

That said, I completely understand this changes the experience for your use case, where you're intentionally connecting to an unavailable server and expecting a fast failure. The default retry configuration (Retry(ExponentialWithJitterBackoff(base=1, cap=10), retries=3)) will indeed add noticeable delay when the server is unreachable.

The solution for your tests is to explicitly disable retries by passing a retry object with 0 retries:

from redis.retry import Retry
from redis.backoff import NoBackoff

conn = Redis(
    port=redis_port(),
    socket_timeout=2.0,
    socket_connect_timeout=2.0,
    retry=Retry(NoBackoff(), 0),
)

[arlosnow1231-stack]

Thank you for the detailed explanation regarding the change in retry behavior.

…

On Wed, Apr 8, 2026, 8:08 AM petyaslavova ***@***.***> wrote: *petyaslavova* left a comment (redis/redis-py#4026) <#4026 (comment)> Hey @carl-mastrangelo <https://github.com/carl-mastrangelo>, thank you for reporting this and for the detailed description of your use case! The behavior you're observing is actually an intentional change rather than a regression. Previously, the client lacked a retry mechanism for cases when handshake commands (like AUTH, SELECT, CLIENT SETINFO, etc.) failed during connection establishment. This was a bug — when retries were enabled, it was inconsistent that the connection handshake phase wouldn't participate in the retry flow. The fix ensures that the entire command execution pipeline, including the initial connection handshake, has retry capability when retries are configured. That said, I completely understand this changes the experience for your use case, where you're intentionally connecting to an unavailable server and expecting a fast failure. The default retry configuration (Retry(ExponentialWithJitterBackoff(base=1, cap=10), retries=3)) will indeed add noticeable delay when the server is unreachable. The solution for your tests is to explicitly disable retries by passing a retry object with 0 retries: from redis.retry import Retryfrom redis.backoff import NoBackoff conn = Redis( port=redis_port(), socket_timeout=2.0, socket_connect_timeout=2.0, retry=Retry(NoBackoff(), 0), ) — Reply to this email directly, view it on GitHub <#4026 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/CAXLFZSO3K2UL4HIUABOAF34UZFOPAVCNFSM6AAAAACXOP3SJSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DEMBWGQ2TGNRYGM> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[AirRunner]

@petyaslavova I understand the intent, but I think this creates a new issue: ENOENT errors (socket file not found) are now subject to the same retry/backoff as transient failures, even though they are definitively unrecoverable, no amount of retrying will make a non-existent file appear.

This is especially problematic in setups where you try a Unix socket first and fall back to TCP if unavailable. With the default Retry(ExponentialWithJitterBackoff(base=1, cap=10), retries=3), the socket attempt alone adds 5-10 seconds of delay, making the fallback pattern unusably slow... without explicitly passing retry=Retry(NoBackoff(), 0), which also disables retry on the handshake.

I believe the ideal fix would be to not retry on unrecoverable errors like ENOENT or ConnectionRefusedError, regardless of the retry policy?

[carl-mastrangelo]

I think it will be pretty difficult to pass in a different retry object for unit tests vs the real system. It's not obvious if we are running inside a test since this code is kind of deep down.

Also, I would expect socket_connect_timeout to take precedence here. Its a signal from users that they want to wait a bounded amount of time. What does it mean when to have this field set with retries? Either the code hangs in the connect call, or it hangs sleeping to try connecting again.

Other remote calls have a concept of fail fast, which gives up on a call if the connection is not ready. I feel like retries are a call-level concept, not a connection level concept.