Add retries to connections in Sentinel Pools

[jdieter]

Pull Request check-list

Please make sure to review and check all of these items:

• Does $ tox pass with this change (including linting)?
• Do the CI tests pass with this change (enable it first in your forked repo and wait for the github action build to finish)?
• Is the new or changed code fully tested?
• Is a documentation update included (if this change modifies existing APIs, or introduces new ones)?
• Is there an example added to the examples folder (if applicable)?

NOTE: these things are not required to open a PR and can be done
afterwards / while the PR is open.

Description of change

Currently, when using sentinel, if a master dies suddenly (i.e. is kill -9'd), and the client is configured with retries, the client will attempt to reconnect to the master using the sentinel pool, as expected.

However, if the sentinels have not yet figured out that the master is dead, a redis.exceptions.ConnectionError will be returned when trying to re-connect to the old master even if ConnectionError is in the list of retry errors.

This PR fixes this by making sure that the initial connection itself in the SentinelPool is also retryable. This has been tested with a script that increments a counter by 1 every second and then running kill -9 on the Redis master. As expected, there's a delay while the sentinels figure out what the new master should be, and then the script continues.

I'm not very familiar with the code, so I'm not sure if this is the ideal place for this code. It is possible that it would make more sense to put it in the connection itself.

While this will need a new test, I'm not sure how to create an automated test that kill -9s one of the Redis servers, I'm not sure if this fix needs documentation, and I'm not sure if I should add an example

[codecov-commenter]

Codecov Report

Merging #1879 (1fd977f) into master (f807f3b) will decrease coverage by 0.63%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master    #1879      +/-   ##
==========================================
- Coverage   93.61%   92.98%   -0.64%     
==========================================
  Files          76       76              
  Lines       16268    16389     +121     
==========================================
+ Hits        15230    15239       +9     
- Misses       1038     1150     +112     

Impacted Files	Coverage Δ
redis/sentinel.py	86.16% <100.00%> (+0.17%)	⬆️
tests/test_ssl.py	48.46% <0.00%> (-5.67%)	⬇️
redis/connection.py	86.78% <0.00%> (-1.56%)	⬇️
redis/commands/core.py	89.92% <0.00%> (-0.02%)	⬇️
redis/ocsp.py	0.00% <0.00%> (ø)
redis/client.py	89.37% <0.00%> (ø)
tests/test_cluster.py	98.28% <0.00%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 0affa0e...1fd977f. Read the comment docs.

[chayim]

@jdieter Thank you for contributing this! It would really help bring the sentinel connection in line with the others!

I can definitely see the argument for adding this to the pool, but I think we probably want this on the SentinelManagedConnection class, instead of the pool itself. This would be consistent with the other retry attempts. WDYT?

[jdieter]

@jdieter Thank you for contributing this! It would really help bring the sentinel connection in line with the others!

I can definitely see the argument for adding this to the pool, but I think we probably want this on the SentinelManagedConnection class, instead of the pool itself. This would be consistent with the other retry attempts. WDYT?

Well, it makes the code significantly easier! :) I've pushed it as a new commitl, but, if you'd prefer, I can merge the two commits into one.

[chayim]

@jdieter Awesome. We're going to roll this into redis-py 4.1.1, the upcoming release. Thank you so much, this is perfect! We squash merge, so all good, all the time.