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

#31838 [Bug]: Redis cache end_user_id:{id} not invalidated on /customer/new, /customer/update, /customer/delete

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

After creating, updating, or deleting a customer via `/customer/new`, `/customer/update`, or `/customer/delete`, the Redis cache key `end_user_id:{id}` (TTL=300s) is not invalidated. Budget enforcement continues using stale data for up to 5 minutes.

**Example 1 (delete + re-create):** 1. Create customer with `max_budget: 0.00001` 2. Make request -> 429 ExceededBudget (expected) 3. Delete customer, then re-create with same `user_id` but `max_budget: 100.0` 4. Check `/customer/info` -> shows correct `max_budget: 100.0`, `spend: 0.0` 5. Make another request -> **429 ExceededBudget** (WRONG! Still using old budget from cache)

**Example 2 (just update via `/customer/update`):** 1. Create customer with `max_budget: 0.00001` 2. Make request -> spend becomes `0.000128` 3. Make request -> 429 ExceededBudget (expected) 4. Update via `/customer/update` with `max_budget: 100.0` 5. Check `/customer/info` -> shows correct `max_budget: 100.0` 6. Make another request -> **429 ExceededBudget: Spend=0.000128, Budget=1e-05** (WRONG! Cache still has old budget) …

GitHub resolver

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

Refresh page
vote history (6 events)
#0 of 0 · 31d19h10m45s ago — entered · #import:https:::github.com:berriai:litellm post #1688
Issue #28021 is harder because it spans UI behavior, API validation, update semantics, and persistence compatibility, while #31838 is a more localized cache-invalidation change across known mutation paths.
The Redis fix has broader scope and higher risk because it requires tracing several proxy mutation paths, ensuring correct cache-key handling and invalidation semantics, and covering consistency and regression cases. The exception change is comparatively localized to error construction, parsing, and SDK tests.
Issue #31838 is harder because it spans multiple backend mutation paths, distributed-cache invalidation semantics, and regression testing for consistency across lifecycle operations. Issue #27292 is narrower UI validation and state-handling work with an existing API path to preserve.
Adding a native provider requires broader integration across LiteLLM’s provider abstractions, request/response translation, authentication, streaming, usage accounting, configuration, documentation, and compatibility testing. The cache defect is narrower: tracing mutation paths, adding consistent invalidation, and covering the affected proxy workflows with regression tests.
The left issue is substantially harder: it spans configuration models, proxy behavior, persistence/deduplication, webhook delivery, multiple entity types, UI changes, backward compatibility, and extensive testing. The right issue is comparatively localized to cache invalidation across a few customer mutation paths.
#0 of 0 · 31d17h41m22s ago — current · #import:https:::github.com:berriai:litellm post #3176
Issue #32221 is harder because it spans multiple synchronous and asynchronous retry paths and must preserve correct exception propagation, HTTP status handling, spend logging, callbacks, and router fallback behavior. Issue #31838 is comparatively localized to adding Redis cache invalidation across customer mutation endpoints and covering it with targeted tests.
discussed in #import:https:::github.com:berriai:litellm

ranked child groups

no voted pairs yet in this scope

cli
src
spread
search