6 views
-/https://github.com/berriai/litellm/issues/27982
GitHub · issue

#27982 [Bug]: Usage UI filters and request logs not working when Redis Cache is enabled

  • State: open
  • Author: @EttyGin
  • Labels: bug, ui-dashboard

### Check for existing issues

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

### What happened?

When litellm_settings: cache: True is enabled with a Redis Cluster configuration, the Usage page in the UI stops functioning correctly.

Specifically: Logs for requests do not appear as expected. Filtering by model, API key, or other parameters does not yield any results.

Configuration used: general_settings: use_redis_transaction_buffer: true litellm_settings: cache: True cache_params: type: redis supported_call_types: []

Environment: LiteLLM Version: 1.83.X Redis cluster

### Steps to Reproduce

1. Enable Redis Cache in the proxy_config.yaml. 2. Send several requests through the proxy. 3. Navigate to the Usage tab in the LiteLLM UI. 4. Attempt to filter by model or key.

Expected behavior The Usage UI should reflect all requests (including cached ones) and allow for standard filtering, regardless of whether caching is active.

Observed behavior The filters fail to return results and the request history is incomplete or missing in the UI when the cache is on.

### Relevant log output

```shell

```

### What…

GitHub resolver

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

Refresh page
vote history (5 events)
#0 of 0 · 31d18h46m22s ago — entered · #import:https:::github.com:berriai:litellm post #2192
Akto requires coordinated guardrail lifecycle changes, streaming buffering/end-of-stream handling, hook semantics, model-group filtering, and integration tests. The Redis-enabled UI defect is narrower, likely involving cache event persistence/query behavior and frontend filtering.
#27982 is harder because it spans Redis-cluster behavior, request persistence, backend filtering/query logic, and UI data handling, with distributed-state and regression risks. #26613 is comparatively narrower: tracing and correcting configuration merging in the proxy request path, plus targeted tests.
The right issue is harder because it likely spans backend data flow, cache consistency, query behavior, and dashboard state, requiring broader debugging and cross-layer regression coverage. The left is comparatively localized to persistence conflict handling and idempotent update logic.
Issue 27982 spans proxy request accounting, Redis caching/transactions, persistence, and UI filtering, creating broader cross-layer debugging and regression risk. Issue 14516 is comparatively localized to guardrail configuration propagation and output handling.
#0 of 0 · 31d17h53m41s ago — current · #import:https:::github.com:berriai:litellm post #3070
27982 requires cross-layer investigation across Redis-backed request persistence, query/filter behavior, and dashboard data handling, with compatibility and regression risks. 30539 is a localized request-transformation fix with comparatively narrow testing.
discussed in #import:https:::github.com:berriai:litellm

ranked child groups

no voted pairs yet in this scope

cli
src
spread
search