make dial timeout per-retry

[mwhooker]

We're noticing an issue where we only ever see
redis: connection pool: failed to dial after 1 attempts: dial tcp x.x.x.x:6379: i/o timeout.

Looking at existing code, it looks like it will never get to a dial retry, because it sets the context timeout to dialtimeout for the entire retry loop. This means that a single dial is the same timeout as all of the dials.

This patch changes behavior so the dial timeout applies dial attempt, rather than all attempts together.

[jit-ci]

Hi, I’m Jit, a friendly security platform designed to help developers build secure applications from day zero with an MVS (Minimal viable security) mindset.

In case there are security findings, they will be communicated to you as a comment inside the PR.

Hope you’ll enjoy using Jit.

Questions? Comments? Want to learn more? Get in touch with us.

[ndyakov]

Hello @mwhooker, thank you for opening this one. I was taking a look at this some time ago and was wondering what would be a users expectation. If there is a dial timeout, should it include the total amount of time for a connection to be established (including retries) or should it be just for a single dial. Based on your PR you would expect this to be per single connection, but does it make sense to have one that is for the whole period?

[mwhooker]

Total dial time is not a value we’re interested in right now, but if it were I imagine we could set it by controlling timeout and number of retries.

…

--Matt Hooker

On Fri, Feb 6, 2026 at 01:31 Nedyalko Dyakov ***@***.***> wrote: *ndyakov* left a comment (redis/go-redis#3705) <#3705 (comment)> Hello @mwhooker <https://github.com/mwhooker>, thank you for opening this one. I was taking a look at this some time ago and was wondering what would be a users expectation. If there is a dial timeout, should it include the total amount of time for a connection to be established (including retries) or should it be just for a single dial. Based on your PR you would expect this to be per single connection, but does it make sense to have one that is for the whole period? — Reply to this email directly, view it on GitHub <#3705 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAD2AX5GLX4H2HD4TSRWT34KRNQHAVCNFSM6AAAAACUFH6JUCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTQNJZGA4DSNJTG4> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[maulin-vasavada]

I think this change makes sense since this simplifies library's user expectation. dialTimeout config always means per dial/connection call. So math of total timeout based on retryCount is easier to do on the user side before choosing values. Currently, prior to this change, I feel it makes it complicated for users to choose because I can imagine when tweaking values for more retries (during prod incident resolution etc) it may be easily forgotten that all retries have to cumulatively meet single dialTimeout config value. To me that is counter-intuitive. Also, this may bring Redis go lib to parity with many other client libs like redis-py and provide consistency for users.

[ndyakov]

@maulin-vasavada we do have a slightly different way of opening connection and retrying compared to redis-py, but i do agree that this can be confusing. will have to run this with our e2e tests around end of week to verify it works as expected in different scenarious.

[ndyakov]

Sorry for the delay, the release we just did took longer than expected. Anyway, this week I will have some cycles to look at this and get back to you.