fix(redis): honor ssl value instead of key presence when building async connection pool

[yassin-berriai]

Relevant issues

Linear ticket

Resolves LIT-4307

Pre-Submission checklist

Please complete all items before asking a LiteLLM maintainer to review your PR

• I have added meaningful tests
• My PR passes all CI/CD checks (e.g., lint, format, unit tests)
• My PR's scope is as isolated as possible; it only solves 1 specific problem
• I have received a Greptile Confidence Score of at least 4/5 before requesting a maintainer review (Greptile reviews automatically once the PR is opened; only comment @greptileai to re-request a review after pushing changes)

Delays in PR merge?

If you're seeing a delay in your PR being merged, ping the LiteLLM Team on Slack (#pr-review).

Screenshots / Proof of Fix

Live proxy on localhost:40307, plaintext Redis on localhost:63407, Postgres-backed, real OpenAI calls. Config sets what a user disabling TLS would write:

litellm_settings:
  cache: true
  cache_params:
    type: redis
    host: localhost
    port: 63407
    ssl: false

Before (unpatched litellm/_redis.py at 142d5aa): every request stalls about 5s on Redis ops because the async pool dials a TLS handshake at a plaintext server, and caching never works

$ for run in 1 2; do curl -s -D - -o resp$run.json -w "time_total: %{time_total}s\n" http://localhost:40307/v1/chat/completions \
    -H "Authorization: Bearer sk-lit4307" -H "Content-Type: application/json" \
    -d '{"model": "gpt-5.5", "messages": [{"role": "user", "content": "What is 2+2? Answer with just the number."}]}' \
    | grep -Ei "^HTTP|x-litellm-cache|x-litellm-overhead|time_total"; done
--- request 1 ---
HTTP/1.1 200 OK
x-litellm-overhead-duration-ms: 5017.592
time_total: 12.816308s
--- request 2 ---
HTTP/1.1 200 OK
x-litellm-cache-key: e34ceac68fe313f2cb4b83aec36f1d56c72f58f51572cccebe677ee49f33c430
x-litellm-overhead-duration-ms: 0.9209999334290624
time_total: 5.024408s

Proxy log during the before run, every async Redis op fails the same way:

LiteLLM Redis Cache PING: - Got exception from REDIS : Timeout connecting to server
LiteLLM Redis Caching: async set() - Got exception from REDIS Timeout connecting to server, ...
Error occurred in async batch get cache - Timeout connecting to server
LiteLLM Redis Caching: async async_increment() - Got exception from REDIS Timeout connecting to server, ...

After (this fix at f7fbb7d), same two curls: overhead drops from 5017ms to 10ms and the second request is a real Redis cache hit

--- request 1 ---
HTTP/1.1 200 OK
x-litellm-overhead-duration-ms: 10.634
time_total: 1.584876s
--- request 2 ---
HTTP/1.1 200 OK
x-litellm-cache-key: e34ceac68fe313f2cb4b83aec36f1d56c72f58f51572cccebe677ee49f33c430
x-litellm-overhead-duration-ms: 0.3112500746324658
time_total: 0.014810s

Redis now actually holds the proxy's keys and the after-run log contains zero Redis errors:

$ docker exec lit4307-redis redis-cli --scan | head -5
{model_per_key:litellm_proxy_master_key:gpt-5.5}:tokens
spend:tag:User-Agent: curl/8.7.1
spend:key:litellm_proxy_master_key
spend:tag:User-Agent: curl
{api_key:litellm_proxy_master_key}:tokens
$ grep -ciE "Got exception from REDIS|Timeout connecting" lit4307-after.log
0

Type

🐛 Bug Fix

Changes

get_redis_connection_pool selected the async connection class by checking whether the ssl key exists in redis_kwargs rather than its value, so ssl: false in cache_params (or REDIS_SSL=false in the environment, which get_secret coerces to bool False but _redis_kwargs_from_environment still forwards because it is not None) produced an SSLConnection against a non-TLS Redis. The handshake never completes, so every async Redis operation (response cache get/set, spend counters, rate limiting, the batch logging writer) blocks until socket_timeout (default 5s) on every request, while the sync client and redis-cli look healthy

The fix branches on the popped value: if redis_kwargs.pop("ssl", None): redis_kwargs["connection_class"] = async_redis.SSLConnection. The ssl key is still always removed since neither async Connection class accepts it as a kwarg. The sync client, cluster, and from_url paths already handle falsy ssl correctly via redis-py itself and are unchanged

This is not a v1.85 to v1.92 regression as originally reported; the identical presence check and pool construction exist in v1.85.0. It is a version-independent bug

Regression tests in tests/test_litellm/test_redis.py pin the connection class for ssl=False (kwarg and REDIS_SSL=false env) to Connection and for ssl=True to SSLConnection, and assert the ssl key never leaks into pool kwargs. The two ssl=False tests fail on the unfixed code

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[greptile-apps]

Greptile Summary

This PR fixes a bug in get_redis_connection_pool where the async connection class was selected based on whether the ssl key existed in redis_kwargs rather than its boolean value, causing ssl=False to incorrectly use SSLConnection and stall every async Redis operation with a 5-second TLS handshake timeout against a plaintext server.

• litellm/_redis.py: Replaces the key-presence check (if "ssl" in redis_kwargs) with a value-truthiness check (if redis_kwargs.pop("ssl", None)), ensuring ssl=False and REDIS_SSL=false both result in the plain Connection class. The pop removes the ssl key in all cases since neither connection class accepts it as a constructor kwarg.
• tests/test_litellm/test_redis.py: Adds three new unit tests covering ssl=False, ssl=True, and the REDIS_SSL=false environment variable path, each asserting the correct connection_class and that the ssl key is absent from pool kwargs. Tests are lazy-connection-only with no real network calls.

Confidence Score: 5/5

Safe to merge — the change is minimal and precisely targeted, with no effect on the sync client, cluster, or from_url paths.

The one-line fix is correct and well-bounded: it only affects the async BlockingConnectionPool path, the ssl key is always removed by pop regardless of its value, and the default behaviour when ssl is absent is unchanged. Three new tests directly validate the fixed behaviour and would catch a revert.

No files require special attention.

Important Files Changed

Filename	Overview
litellm/_redis.py	Fixes async connection pool SSL selection: branches on the ssl value (truthy check via pop) instead of key presence, so ssl=False no longer forces SSLConnection. The ssl key is removed in all cases since neither connection class accepts it as a kwarg.
tests/test_litellm/test_redis.py	Adds three new regression tests covering ssl=False (direct kwarg), ssl=True (direct kwarg), and REDIS_SSL=false (env var). Tests only inspect pool attributes — no real network calls are made since BlockingConnectionPool is lazy.

_{Reviews (1): Last reviewed commit: "fix(redis): honor ssl value instead of k..." | Re-trigger Greptile}

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[codspeed-hq]

Merging this PR will not alter performance

✅ 31 untouched benchmarks

---

_{Comparing litellm_fix_redis_pool_ssl_false (5fbc627) with litellm_internal_staging (4580ad0)}