BerriAI/litellm · error · HTTPException

Error fetching cache settings: {e}

Error message

Error fetching cache settings: {e}

What it means

GET /cache/settings builds the cache-configuration view for the Admin UI: field definitions, current values, and Redis type descriptions. The whole flow is wrapped in try/except; any exception while reading current values (proxy config, LiteLLM_CacheConfig table) or assembling the response is logged by verbose_proxy_logger as 'Error fetching cache settings: <e>' and re-raised as HTTP 500 with the underlying exception interpolated into the detail. The message is a wrapper — the real cause is in the proxy logs.

Source

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

                effective["redis_type"] = "node"

        # Redact credential fields so the GET response never carries a plaintext
        # Redis / Sentinel password off the server.
        current_values: Final = _redact_credentials(effective)

        # Update field values with current values
        for field in cache_fields:
            if field.field_name in current_values:
                field.field_value = current_values[field.field_name]

        return CacheSettingsResponse(
            fields=cache_fields,
            current_values=current_values,
            redis_type_descriptions=REDIS_TYPE_DESCRIPTIONS,
        )
    except Exception as e:
        verbose_proxy_logger.error("Error fetching cache settings: %s", e)
        raise HTTPException(status_code=500, detail=f"Error fetching cache settings: {e}")


@router.post(
    "/cache/settings/test",
    tags=["Cache Settings"],
    dependencies=[Depends(user_api_key_auth)],
    response_model=CacheTestResponse,
)
async def test_cache_connection(
    request: CacheTestRequest,
    user_api_key_dict: UserAPIKeyAuth = Depends(user_api_key_auth),
):
    """
    Test cache connection with provided credentials.

    Creates a temporary cache instance and uses its test_connection method
    to verify the credentials work without affecting global state.
    """

View on GitHub (pinned to 77b7c6c40c)

Solutions

  1. Read the proxy logs: the 'Error fetching cache settings: <e>' line contains the true underlying exception and stack trace
  2. Verify DB connectivity and that the LiteLLM_CacheConfig table exists (restart the proxy to re-run Prisma migrations)
  3. Inspect the LiteLLM_CacheConfig row with id='cache_config'; fix malformed JSON or delete the row so defaults regenerate on next save
  4. If the data looks fine, match the error against recent version changes and report with the logged stack trace
Defensive patterns

Strategy: retry

Validate before calling

import httpx

# Cheap pre-flight: a DB-backed read that the settings view depends on
r = httpx.get(f"{PROXY_URL}/health/liveliness")
if r.status_code != 200:
    print("proxy unhealthy; /cache/settings will likely fail")

Try / catch

import httpx, time

def get_cache_settings(url, hdrs, attempts=3):
    for i in range(attempts):
        try:
            r = httpx.get(f"{url}/cache/settings", headers=hdrs, timeout=10)
            if r.status_code == 200:
                return r.json()
            if r.status_code == 500 and "Error fetching cache settings" in r.text:
                # underlying cause is in server logs; retry only transient DB issues
                time.sleep(2 ** i)
                continue
            r.raise_for_status()
        except httpx.TransportError:
            time.sleep(2 ** i)
    raise RuntimeError("cache settings fetch kept failing; inspect proxy logs for root cause")

Prevention

When it happens

Trigger: GET /cache/settings when reading/parsing the stored cache config fails: corrupted or legacy-format settings JSON in LiteLLM_CacheConfig, a Prisma/DB error mid-request, or cached values that no longer round-trip through the current field models after an upgrade.

Common situations: Upgrading the LiteLLM proxy across versions where the cache-settings schema changed; a partially written cache_config row from a crashed earlier update; transient Postgres failover or connection pool exhaustion during the request.

Related errors

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