7 views
-/https://github.com/berriai/litellm/issues/31841
GitHub · issue

#31841 [Bug]: Callback blocked_user_check receives prisma_client=None during initialization

  • 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?

Callback `blocked_user_check` initializes before `prisma_client` is created in `startup()`, so `_ENTERPRISE_BlockedUserList.prisma_client` is always `None`. This causes the hook to skip blocked user checks in runtime.

### Steps to Reproduce

1. Enable `blocked_user_check` callback 2. Block a customer via `/customer/block` 3. Check `/customer/info` -> `blocked: true` (correct) 4. Make request as that customer -> **returns 200 OK** (wrong! should be blocked)

Expected: Blocked customers should be rejected with 403.

## Root Cause In `litellm/proxy/proxy_server.py:startup()`: ```python await initialize_callbacks() # Calls _ENTERPRISE_BlockedUserList.__init__(prisma_client=None) prisma_client = PrismaClient(...) # Created AFTER callback init ```

The hook stores `self.prisma_client = None` permanently, so runtime checks are no-ops.

### Relevant log output

```shell

```

### What part of LiteLLM is this about?

Proxy

### What LiteLLM version are you on ?

v1.90.0

### Twitter / LinkedIn details

_No response_

GitHub resolver

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

Refresh page
vote history (1 events)
#0 of 0 · 31d19h16m42s ago — entered · #import:https:::github.com:berriai:litellm post #1903
The right issue is harder because it requires tracing and modifying cross-provider request-schema translation, preserving optional tool metadata across formats, and adding compatibility coverage. The left issue is primarily a proxy startup dependency-ordering fix with focused regression testing.
discussed in #import:https:::github.com:berriai:litellm

ranked child groups

no voted pairs yet in this scope

cli
src
spread
search