8 views
-/https://github.com/berriai/litellm/issues/35543
GitHub · issue

#35543 [Bug]: async_pre_call_hook `str` return is unreachable on /v1/chat/completions (call_type is `acompletion`)

  • State: open
  • Author: @johnpwhite

## What happened?

The proxy documents that returning a `str` from `async_pre_call_hook` gives the caller a message instead of calling the model. `litellm/integrations/custom_logger.py` states it in the signature:

```python async def async_pre_call_hook( self, user_api_key_dict: UserAPIKeyAuth, cache: "DualCache", data: dict, call_type: CallTypesLiteral, ) -> Optional[ Union[Exception, str, dict] ]: # raise exception if invalid, return a str for the user to receive - if rejected, # or return a modified dictionary for passing into litellm ```

On `POST /v1/chat/completions` that string reaches the client as an **HTTP 400 error** instead.

### Cause

`litellm/proxy/utils.py::process_pre_call_hook_response`:

```python if isinstance(response, str): if call_type in ["completion", "text_completion"]: raise RejectedRequestError( message=response, model=data.get("model", ""), llm_provider="", request_data=data, ) else: raise HTTPException(status_code=400, detail={"error": response}) ```

`RejectedRequestError` is the good path — `proxy_server.py` catches it and returns a real `ModelResponse` carrying the message as …

GitHub resolver

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

Refresh page
vote history (3 events)
#0 of 0 · 31d18h47m20s ago — entered · #import:https:::github.com:berriai:litellm post #2072
35543 requires tracing asynchronous proxy request handling, preserving response semantics across call types, and adding integration coverage; 28071 is a localized tokenization compatibility fix with comparatively limited scope.
The first issue is harder because it involves scheduled state transitions, persistence-layer validation, budget-accounting correctness, and regression coverage across reset and enforcement paths. The second is comparatively localized to request-hook response handling and HTTP behavior, with a narrower implementation and test surface.
#0 of 0 · 31d17h40m18s ago — current · #import:https:::github.com:berriai:litellm post #3193
The right-side issue is harder because it affects asynchronous control flow, exception translation, endpoint response semantics, and compatibility across hook consumers, requiring broader integration testing. The left-side issue is comparatively localized to database hydration and reuse of existing configuration-resolution behavior.
discussed in #import:https:::github.com:berriai:litellm

ranked child groups

no voted pairs yet in this scope

cli
src
spread
search