8 views
-/https://github.com/berriai/litellm/issues/31206
GitHub · issue

#31206 [Bug]: REDIS_CLUSTER_NODES causes proxy shutdown to fail

  • State: open
  • Author: @pmlanger
  • Labels: bug, proxy

### Check for existing issues

- [x] I have searched the existing issues and checked that my issue is not a duplicate.

### What happened?

Setting `REDIS_CLUSTER_NODES` causes the application shutdown to fail (see logs).

Observed on litellm:v1.83.3-stable. However, I think the codepath is still active on `litellm_internal_staging`. I'm a bit new here, so forgive me if I haven't followed the path correctly.

Here's my theory:

In _redis.py: `if "startup_nodes" in redis_kwargs: return None` means `get_redis_connection_pool()` returns `None` if `REDIS_CLUSTER_NODES` is set. (https://github.com/BerriAI/litellm/blob/8bca05d311ab3ce9b0d213a3bcd2d9d503fc7477/litellm/_redis.py#L668-L669)

This means that `RedisCache.__init__` sets `self.async_redis_conn_pool = None` (https://github.com/BerriAI/litellm/blob/8bca05d311ab3ce9b0d213a3bcd2d9d503fc7477/litellm/caching/redis_cache.py#L239)

However, on shutdown, `disconnect` is called, which does not expect `async_redis_conn_pool` to be `None`: https://github.com/BerriAI/litellm/blob/8bca05d311ab3ce9b0d213a3bcd2d9d503fc7477/litellm/caching/redis_cache.py#L1278

An `if None:` guard in `disconnect` should fix this. I can provide a PR if you agree…

GitHub resolver

Import GitHub neighbors on demand. Results are saved as system ingests.

Refresh page
vote history (3 events)
#0 of 0 · 31d19h7m21s ago — entered · #import:https:::github.com:berriai:litellm post #1746
The right-hand task is substantially harder because it involves a breaking third-party SDK migration, dependency changes, API and lifecycle compatibility work, and broad regression testing. The left-hand task is a localized shutdown null-safety fix with limited scope.
Tag budget resetting spans scheduled job behavior, persistence semantics, and regression coverage across recurring budget cycles, making it substantially broader and riskier than a localized shutdown null-guard fix.
#0 of 0 · 31d18h57m48s ago — current · #import:https:::github.com:berriai:litellm post #1892
The left issue is harder because it likely requires cross-layer investigation of long-running request lifecycles, transport timeouts, cancellation, and streaming behavior, with difficult reproduction and broader regression testing. The right issue appears localized to defensive resource-cleanup handling with a straightforward targeted test.
discussed in #import:https:::github.com:berriai:litellm

ranked child groups

no voted pairs yet in this scope

cli
src
spread
search