4.6.0 - ConnectionError max number of clients reached

TL;DR

[kristjanvalur (contributor)]: Redis Sentinel's masterfor/slavefor did not set up the client correctly, leaking connections. Fixed by PR #2900 (merged).

Steps

1. [kristjanvalur (contributor)]: Redis Sentinel's masterfor/slavefor did not set up the client correctly, leaking connections. Fixed by PR #2900 (merged). Workaround on older versions: set client.autocloseconnectionpool = True after masterfor. Reporters confirmed stable client counts on 5.0 with connections closed via context managers.

When to use

You are seeing this: Redis Vector Search - Version: 4.6.0 Platform: Python 3.10 / Docker or Linux Server : Redis 7.0.11 Description: We have an application using redis in an async context for months now. Use this skill when you run into "4.6.0 - ConnectionError max number of clients reached".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

Versions mentioned in the source: 4.6.0, Redis 7.0.11. If you are on something much newer or older, the details may have shifted.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

Sources

• https://github.com/redis/redis-py/issues/2831

In gh:redis/redis-py#2831 (https://github.com/redis/redis-py/issues/2831), the issue reported: Version: 4.6.0

Platform: Python 3.10 / Docker or Linux

Server : Redis 7.0.11

Description:

We have an application using redis in an async context for months now. With the ugrade of redis-py from 4.5.x to 4.6.0, we saw our app on staging environment starts failing with ConnectionError max number of clients reached

I first run a review of the code to add the missing await redis_conn.close() statements that were missing but the issue still occurs.

It seems that we reach the 10.000 max clients settings in one hour approx whereas we never used to so far.... The verified answer: [kristjanvalur (contributor)]: Redis Sentinel's masterfor/slavefor did not set up the client correctly, leaking connections. Fixed by PR #2900 (merged). Workaround on older versions: set client.autocloseconnectionpool = True after masterfor. Reporters confirmed stable client counts on 5.0 with connections closed via context managers.