fix: convert Chat Completions 'file' type to Responses API 'input_file' format
When using /chat/completions with type: "file" content against an Azure
model configured with mode: "responses", LiteLLM incorrectly converts
the file content to input_text instead of input_file.
This fix adds proper handling for the 'file' type in the
_convert_content_to_responses_format method, converting:
- Chat Completions: {"type": "file", "file": {"file_data": "...", "filename": "..."}}
- Responses API: {"type": "input_file", "file_data": "...", "filename": "..."}
Fixes #23588
Support multiple headers mapped to the customer user role (#23664)
* added the header mapping feature
* added tests
* final cleanup
* final cleanup
* added missing test and logic
* fixed header sending bug
* Update litellm/proxy/auth/auth_utils.py
Co-authored-by: greptile-apps[bot] <165735046+greptile-apps[bot]@users.noreply.github.com>
* added back init file in responses + fixed test_auth_utils.py int local_testing
---------
Co-authored-by: greptile-apps[bot] <165735046+greptile-apps[bot]@users.noreply.github.com>
fix(guardrails): add 'block' as valid on_violation value in BaseLitellmParams
Guardrail configs loaded from the database can have on_violation='block'
(a natural choice for "block the request"). The current Pydantic schema
only accepts Literal["warn", "end_session"], causing a validation error:
Input should be 'warn' or 'end_session' [type=literal_error, input_value='block', ...]
Add 'block' to the Literal type so existing configs with on_violation='block'
are accepted instead of crashing the proxy on startup.
Fixes #23624