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.

[sean-kim05]

Thanks @petyaslavova for clarifying that retrying the handshake phase is intentional — that makes sense and I'm not suggesting reverting it. I'd like to pick up the narrower problem @AirRunner raised, since it looks separable from the intentional retry behavior: definitively-unrecoverable connection errors are retried with full backoff.

Root cause (sync and async are identical)

Connection.connect() wraps the whole connect + handshake in the outer retry:

# redis/connection.py:1007  (redis/asyncio/connection.py:351)
self.retry.call_with_retry(
    lambda: self.connect_check_health(check_health=True, retry_socket_connect=False),
    lambda error: self.disconnect(error),
)

During socket establishment, every OSError is caught and re-wrapped into a generic ConnectionError:

# redis/connection.py:1046-1047  (redis/asyncio/connection.py:397-398)
except OSError as e:
    e = ConnectionError(self._error_message(e))
    raise e

Because the outer retry's _supported_errors includes ConnectionError, this is retried up to DEFAULT_RETRY_COUNT (10) times with exponential backoff — even for errors that can never succeed on retry, e.g. a Unix-domain-socket ENOENT (the socket path simply doesn't exist). The wrap also discards the original errno, so nothing downstream can distinguish a permanent failure from a transient one.

Net effect: Redis(unix_socket_path=..., socket_connect_timeout=2) against a missing socket spends seconds sleeping/retrying, and the common "try UDS, fall back to TCP" pattern becomes very slow.

Proposed approach (small, uses existing machinery)

call_with_retry already accepts an is_retryable predicate that connect() simply doesn't pass today:

# redis/retry.py:121-123  (async equivalent: redis/asyncio/retry.py:71)
except self._supported_errors as error:
    if is_retryable and not is_retryable(error):
        raise

So the change could be:

1. Preserve the original error when wrapping (raise ConnectionError(...) from e, or carry e.errno), so it can be classified.
2. Pass an is_retryable predicate from connect() that returns False for a small set of definitively-unrecoverable socket errnos (starting conservatively with ENOENT) — those fail fast, while transient errors like ECONNREFUSED during server startup keep retrying exactly as they do now.

This keeps the intentional handshake-retry behavior fully intact and only changes the "no point retrying" cases.

A few design questions before I write it

1. Scope of "unrecoverable": start with just ENOENT, or also include e.g. EACCES / EAFNOSUPPORT / EPROTONOSUPPORT? I'd lean conservative (ENOENT only) to avoid surprises.
2. socket_connect_timeout as a hard cap: separately, @carl-mastrangelo expected socket_connect_timeout to bound total connect time. That's a broader change (a deadline carried across retries) — worth folding in here, or keep it out of scope?
3. Default vs opt-in: not retrying ENOENT seems strictly desirable as the default — agreed, or would you prefer it gated behind a flag?

Happy to implement this (sync + async, with tests) once you point me at the preferred direction. Thanks!