Race condition on counter initialization under-counts spend

There is a check-then-set race between concurrent pods at cold start. Both pods may see current is None simultaneously, each read the same base_spend from user_api_key_cache, then one pod's async_set_cache will overwrite the Redis key after the other pod has already incremented it — dropping that increment.

Example sequence (two pods, both cold on the same token, base_spend=5.0):

1. Pod A: async_get_cache → None
2. Pod B: async_get_cache → None
3. Pod A: set_cache(5.0) → Redis = 5.0
4. Pod A: increment_cache(+0.30) → Redis = 5.30
5. Pod B: set_cache(5.0) → Redis = 5.0 (overwrites 5.30)
6. Pod B: increment_cache(+0.40) → Redis = 5.40

Final: 5.40 instead of 5.70 — 0.30 is silently lost. During a burst of concurrent cold-start requests this can under-count spend by multiple increments, defeating the budget enforcement goal.

The safest Redis-native fix is to skip the separate set_cache entirely and rely on a Lua SET key base NX + INCRBYFLOAT combination (SET only if not exists). A pragmatic alternative is to omit the initialization step and use INCRBYFLOAT starting from 0, then reconcile against the DB spend value in get_current_spend rather than seeding the counter from the DB object.

Team member spend counters are never reset

_reset_budget_common is called with item_type in {"key", "team", "user"}. The code resets Redis counters for keys and teams, but there is no reset for team member counters under the spend:team_member:{user_id}:{team_id} key pattern.

This means that after a budget period resets (e.g., monthly), the Redis counter for a team member retains its accumulated value. On the next request that team member will be treated as having already spent their previous period's amount, and they will be permanently rate-limited until the Redis counter naturally expires or is manually cleared.

The reset job does not have a _reset_budget_for_team_member path at the moment, so team member counters have no reset path at all. This is a material gap given the PR's stated goal of reliable multi-pod budget enforcement.

Silent Redis exception swallowing makes failures invisible

The bare except Exception: pass swallows all Redis read errors with no log output. When Redis is temporarily unavailable this silently degrades to in-memory (per-pod) spend enforcement without any indication, making it very hard to diagnose why budgets are not being enforced after a Redis outage. Consider logging at debug level so that operators can trace the fallback path.

The spend counter uses a heuristic to decide whether to hash the proxy API key based on the prefix \"sk-\". If a raw proxy API key does not start with \"sk-\", its raw value will be embedded directly into Redis/in-memory cache keys (e.g., spend:key:<raw_token>), exposing a secret in the cache namespace. This violates the project's proxy key handling rules and creates a realistic secret leakage path via cache backends or any tooling that lists keys.

Vulnerable code:

if token is not None:
    hashed_token = (
        hash_token(token=token)
        if isinstance(token, str) and token.startswith("sk-")
        else token
    )
    await _init_and_increment_spend_counter(
        counter_key=f"spend:key:{hashed_token}",
        source_cache_key=hashed_token,
        increment=response_cost,
    )

Impact:

• Raw proxy API keys may be stored and retrievable from Redis or logs/metrics that capture key names, enabling unauthorized use of the proxy by anyone with access to the cache backend or operational logs.

Remediation:

• Always use the hashed token for cache key construction. Do not rely on string-prefix heuristics. Ensure token is consistently a hashed value at this point in the flow, or perform a robust check/normalization that guarantees hashing of any raw proxy key before use. Also ensure any other paths that set or read spend keys use the hashed form consistently.

For more details, see the finding in Corridor.

Provide feedback: Reply with whether this is a valid vulnerability or false positive to help improve Corridor's accuracy.

Silent Redis counter reset failure causes permanent over-enforcement

spend_counter_cache.async_set_cache(...) internally swallows Redis write errors — its own try/except catches exceptions and logs without re-raising. This means when Redis has a transient error during a budget reset, the call returns without error, but the Redis counter still holds the old spend value.

The critical problem: get_current_spend always reads Redis first (bypassing DualCache's in-memory fallback), so after a silently-failed reset:

• In-memory counter: correctly reset to 0.0
• Redis counter: still holds the old period's spend
• Next get_current_spend call returns the stale Redis value → budget check blocks the user permanently

This failure mode is newly introduced by this PR because the direct Redis read in get_current_spend creates an asymmetry with DualCache's error-swallowing write path. Before this PR, there were no Redis-backed counters, so there was no persistent state to get stuck.

The same risk applies to the team branch here and to the reset_budget_for_litellm_team_members function.

A safe fix is to call spend_counter_cache.redis_cache.async_set_cache(...) directly when redis_cache is not None, wrapped in its own try/except that emits a WARNING-level log (not just debug), so operators can detect stuck counters. The in-memory reset can still proceed unconditionally as a local fallback.