10 views
-/https://github.com/berriai/litellm/issues/25447
GitHub · issue

#25447 [Bug]: Critical: Response leakage / Cross-talk between users in Redis Cluster environment on OpenShift

  • State: open
  • Author: @randomkrml
  • 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?

Hi,

We're seeing an issue in a distributed setup where responses occasionally seem to be returned to the wrong client.

Environment

- OpenShift (multiple replicas) - Image: litellm-database (v1.81.3+) - Redis Cluster enabled - Behavior

Under concurrent load, it looks like a response generated for one request is sometimes returned to another client.

We noticed this happens more often when multiple sessions are using the same API key.

Question: Is there any known limitation or configuration requirement when using LiteLLM with: Redis Cluster Multiple replicas Shared API keys

Specifically, could this be related to caching or request scoping?

Would appreciate guidance on the correct configuration to ensure proper isolation between requests.

Thanks!

### Steps to Reproduce

.

### Relevant log output

```shell

```

### What part of LiteLLM is this about?

Proxy

### What LiteLLM version are you on ?

v1.81.3

### Twitter / LinkedIn details

_No response_

GitHub resolver

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

Refresh page
vote history (7 events)
#0 of 0 · 31d18h33m41s ago — entered · #import:https:::github.com:berriai:litellm post #2324
Native NeMo Guardrails support spans multiple public interfaces, configuration and dependency management, request/response interception, and compatibility with existing proxy guardrail flows. The Redis issue is high-risk but more narrowly scoped to diagnosing request isolation, cache keying, and distributed concurrency behavior.
The left issue is narrower operational-state handling: enforcing readiness, preserving a valid model snapshot, and adding retry/recovery behavior around transient dependency failures. The right issue is substantially riskier because it involves distributed concurrency, cache key/request isolation, Redis Cluster semantics, and potential security-sensitive data leakage; diagnosing it requires reliable reproduction and broad auditing to avoid regressions.
The right issue is harder because it requires diagnosing and correcting nondeterministic cross-request isolation in a distributed, concurrent Redis-backed deployment, with significant security and regression risk. The left issue spans quota accounting, calendar/timezone handling, APIs, and UI, but has a more bounded design and implementation path.
#25447 is harder because it requires diagnosing and preventing a high-severity distributed concurrency and data-isolation failure across replicas and Redis Cluster, with difficult reproduction and correctness risks. #31835 is broader than a simple endpoint but can be implemented as a more bounded administrative workflow with explicit policy handling, idempotency, and auditability.
29320 requires a broad new integration spanning request processing, configuration, proxy and SDK paths, fail-open behavior, and observability. 25447 may involve difficult distributed-state debugging, but its implementation scope is narrower and depends on reproducing and isolating an existing defect.
Distributed concurrency and data-isolation failures require difficult reproduction, diagnosis, and correctness validation across Redis Cluster and replicas, with substantial security risk; the self-service feature is broader in surface area but comparatively straightforward application, authorization, aggregation, and UI work.
#0 of 0 · 31d17h20m45s ago — current · #import:https:::github.com:berriai:litellm post #3534
The left issue is harder because it involves diagnosing and safely correcting distributed request isolation under concurrency, with substantial security, caching, deployment, and regression risk. The right issue is comparatively scoped to aligning identifiers across logging and persistence paths.
discussed in #import:https:::github.com:berriai:litellm

ranked child groups

no voted pairs yet in this scope

cli
src
spread
search