PR #24731: fix(proxy): restore deprecated key auth cache lookups

• Repository: BerriAI/litellm
• Author: imleooooo
• State: open | merged: False
• Link: https://github.com/BerriAI/litellm/pull/24731

Description (problem / solution / changelog)

Relevant issues

Fixes #24680

Pre-Submission checklist

Please complete all items before asking a LiteLLM maintainer to review your PR

• I have Added testing in the [tests/test_litellm/](https://github.com/BerriAI/ litellm/tree/main/tests/test_litellm) directory, Adding at least 1 test is a hard requirement - see details
• My PR passes all unit tests on [make test-unit](https://docs.litellm.ai/docs/ extras/contributing_code)
• My PR's scope is as isolated as possible, it only solves 1 specific problem
• I have requested a Greptile review by commenting @greptileai and received a Confidence Score of at least 4/5 before requesting a maintainer review

Delays in PR merge?

If you're seeing a delay in your PR being merged, ping the LiteLLM Team on [Slack (#pr- review)](https://join.slack.com/t/litellmossslack/shared_invite/zt-3o7nkuyfr- p_kbNJj8taRfXGgQI1~YyA).

CI (LiteLLM team)

CI status guideline:

• 50-55 passing tests: main is stable with minor issues.
• 45-49 passing tests: acceptable but needs attention
• <= 40 passing tests: unstable; be careful with your merges and assess the risk.

• Branch creation CI run Link:

• CI run for the last commit Link:

• Merge / cherry-pick CI run Links:

Type

🐛 Bug Fix

Changes

Problem

After upgrading to v1.82.3, some previously valid LiteLLM virtual keys started failing auth with:

Authentication Error, Invalid proxy server token passed ... Unable to find token in cache or LiteLLM_VerificationTokenTable

This affects keys that are still expected to work during the deprecated-key grace period after regeneration / rotation.

Root cause

LiteLLM supports grace-period auth for rotated keys via _lookup_deprecated_key(), which checks LiteLLM_DeprecatedVerificationToken and caches old-key -> active-key mappings in memory.

The bug was in the in-memory cache tuple handling:

• cache reads expected 3 values:
  • active_token_id
  • cache_expires_at_ts
  • revoke_at_ts
• cache writes only stored 2 values:
  • active_token_id
  • cache_expires_at_ts

That means the first deprecated-key lookup could succeed from DB, but the next lookup could fail when reading the malformed cache entry. In practice this breaks auth for keys relying on the deprecated-key grace-period fallback and surfaces as token_not_found_in_db.

Fix

This PR updates litellm/proxy/utils.py to make deprecated-key cache reads and writes consistent:

• store revoke_at.timestamp() in the cache tuple
• support both the new 3-field tuple and legacy 2-field tuples when reading
• evict malformed cache entries safely
• remove the duplicate cache read in _lookup_deprecated_key()

Test

Added a regression test in tests/test_litellm/proxy/auth/test_user_api_key_auth.py to verify:

• the first deprecated-key lookup resolves via DB
• the second lookup resolves from the in-memory cache
• the cached path no longer breaks auth

Local verification completed:

• tests/test_litellm/proxy/auth/test_user_api_key_auth.py -k deprecated_key_uses_cache_on_subsequent_requests

Changed files

• litellm/proxy/utils.py (modified, +25/-5)
• tests/test_litellm/proxy/auth/test_user_api_key_auth.py (modified, +38/-9)