BerriAI/litellm · error · HTTPException

Error updating cache settings: {e}

Error message

Error updating cache settings: {e}

What it means

POST /cache/settings wraps encryption, the LiteLLM_CacheConfig upsert, audit logging, and cache reinitialization in one try/except. Any failure in that chain is logged as 'Error updating cache settings: <e>' and returned as HTTP 500 with the underlying exception text. Common real causes include invalid Redis credentials/hosts supplied in the settings payload, encryption failures when saving sensitive fields (e.g. no master key configured for encrypting secrets), and DB write errors.

Source

Thrown at litellm/proxy/management_endpoints/cache_settings_endpoints.py:673

        # control where LLM responses are cached.  An admin (or compromised
        # admin) flipping the cache backend silently is a data-routing
        # pivot; emit an audit-log row so the action is traceable.
        await _emit_cache_settings_audit_log(
            action=action,
            before_settings=before_settings,
            after_settings=cache_settings,
            user_api_key_dict=user_api_key_dict,
            litellm_changed_by=litellm_changed_by,
        )

        return {
            "message": "Cache settings updated successfully",
            "status": "success",
            "settings": _redact_credentials(cache_settings),
        }
    except Exception as e:
        verbose_proxy_logger.error("Error updating cache settings: %s", e)
        raise HTTPException(status_code=500, detail=f"Error updating cache settings: {e}")

View on GitHub (pinned to 77b7c6c40c)

Solutions

  1. Check the proxy log line 'Error updating cache settings: <e>' — it names the exact failing step
  2. If it names Redis: validate credentials separately with POST /cache/settings/test before saving, fix host/port/password/TLS settings
  3. If it names encryption/DB: verify DATABASE_URL connectivity and the encryption setup for secrets, then retry
  4. If the stored row is corrupted, clear LiteLLM_CacheConfig id='cache_config' and re-save fresh settings

Example fix

# before: untested credentials go straight to save
curl -X POST http://localhost:4000/cache/settings -d '{"redis_url": "redis://wrong:6379", ...}'

# after: test first, then save
curl -X POST http://localhost:4000/cache/settings/test -d '{"redis_url": "redis://right:6379", ...}'  # 200
curl -X POST http://localhost:4000/cache/settings -d '{"redis_url": "redis://right:6379", ...}'  # 200
Defensive patterns

Strategy: retry

Validate before calling

import httpx

# Validate Redis credentials with the dedicated test route BEFORE saving
r = httpx.post(f"{PROXY_URL}/cache/settings/test", json={
    "redis_url": settings["redis_url"],
}, headers=hdrs)
assert r.status_code == 200 and r.json().get("status") != "error", f"cache test failed: {r.text}"

Try / catch

import httpx, time

def save_cache_settings(url, hdrs, payload, attempts=3):
    for i in range(attempts):
        r = httpx.post(f"{url}/cache/settings", json=payload, headers=hdrs, timeout=30)
        if r.status_code == 200:
            return r.json()
        if r.status_code == 500 and "Error updating cache settings" in r.text:
            cause = r.text  # contains underlying exception; only retry if transient (e.g. conn drop)
            time.sleep(2 ** i)
            continue
        r.raise_for_status()
    raise RuntimeError(f"cache settings update failed repeatedly: {cause}")

Prevention

When it happens

Trigger: POST /cache/settings with a Redis URL/password that cannot be reached or authenticated; saving passwords when the deployment lacks the required encryption setup; a DB constraint/connection failure during the LiteLLM_CacheConfig upsert; invalid field values rejected during reinitialization.

Common situations: Typo'd Redis host or port in the Admin UI cache form; rotating Redis credentials but saving the old password; DB failover mid-update; versions where the settings row schema changed and the upsert conflicts.

Related errors


AI-assisted analysis of BerriAI/litellm@77b7c6c40c (2026-08-18). Data as JSON: /api/errors/837e0dc41a6879f7. Report an issue: GitHub.