Issue Station
Sign In
Tools hereToolbox

litellm - ✅(Solved) Fix [Bug]: Mistral document file translation [1 pull requests, 1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
BerriAI/litellm#25531•Fetched 2026-04-11 06:13:34
View on GitHub
Comments
1
Participants
2
Timeline
6
Reactions
0
Author
asmirnov-tbaasmirnov-tba
Participants
asmirnov-tbaasmirnov-tbabalgalybalgaly
Timeline (top)
labeled ×3commented ×1cross-referenced ×1referenced ×1

Root Cause

Problem When sending a PDF file using OpenAI's "type": "file" content format through LiteLLM to a Mistral backend, LiteLLM passes the payload through untranslated. Mistral rejects it because it only accepts "type": "document_url".

Fix Action

Fixed

PR fix notes

PR #25536: fix(mistral): translate file_data to document_url in chat messages

Description (problem / solution / changelog)

Description

Fixes #25531

When a user sends an OpenAI-format "type": "file" content block with file_data (a base64 data URI) to a Mistral backend through LiteLLM, the payload was passed through untranslated. Mistral rejects it with HTTP 422 because it only accepts "type": "document_url".

LiteLLM already correctly translates "type": "file" for Gemini (to inline_data), but was missing the equivalent translation for Mistral.

Root cause

_handle_message_with_file in litellm/llms/mistral/chat/transformation.py only handled the file_id case (uploaded file IDs). It did not handle file_data (base64 data URIs).

Fix

Extend _handle_message_with_file to handle both cases:

InputMistral output
{"type": "file", "file": {"file_data": "data:application/pdf;base64,..."}}{"type": "document_url", "document_url": "data:application/pdf;base64,..."}
{"type": "file", "file": {"file_id": "file-xxx"}}{"type": "file", "file_id": "file-xxx"} (unchanged)

Testing

Added 4 new tests to tests/test_litellm/llms/mistral/test_mistral_chat_transformation.py::TestMistralFileHandling:

  • test_handle_file_message_with_file_data_converts_to_document_url — core fix
  • test_handle_file_message_file_data_takes_priority_over_file_id — both fields present
  • test_transform_messages_sync_translates_file_data_to_document_url — full pipeline
  • All 33 existing Mistral chat transformation tests continue to pass

Checklist

  • Tests added (4 new unit tests, all mocked)
  • make test-unit passes for this test file
  • Black formatting applied (poetry run black .)
  • Scope isolated to this single bug

Changed files

  • litellm/llms/mistral/chat/transformation.py (modified, +16/-9)
  • tests/test_litellm/llms/mistral/test_mistral_chat_transformation.py (modified, +94/-9)

Code Example

model_list:
  - model_name: mistral/mistral-small-latest
    litellm_params:
      model: mistral/mistral-small-latest
      api_key: "<MISTRAL_API_KEY>"

---

curl -X POST http://localhost:4000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer <LITELLM_KEY>" \
  -d '{
    "model": "mistral/mistral-small-latest",
    "messages": [{
      "role": "user",
      "content": [
        {
          "type": "file",
          "file": {
            "filename": "test.pdf",
            "file_data": "data:application/pdf;base64,<BASE64_PDF>"
          }
        },
        {"type": "text", "text": "What text does this PDF contain?"}
      ]
    }]
  }'

---

{
  "type": "document_url",
  "document_url": "data:application/pdf;base64,<BASE64_PDF>"
}

---
RAW_BUFFERClick to expand / collapse

Check for existing issues

  • I have searched the existing issues and checked that my issue is not a duplicate.

What happened?

Title: "type": "file" content not translated to "type": "document_url" for Mistral provider

Labels: bug, mistral

Description:

Problem When sending a PDF file using OpenAI's "type": "file" content format through LiteLLM to a Mistral backend, LiteLLM passes the payload through untranslated. Mistral rejects it because it only accepts "type": "document_url".

LiteLLM correctly translates "type": "file" to Gemini's native inline_data format, but does not perform the equivalent translation for Mistral.

Steps to Reproduce

LiteLLM config:

model_list:
  - model_name: mistral/mistral-small-latest
    litellm_params:
      model: mistral/mistral-small-latest
      api_key: "<MISTRAL_API_KEY>"

Request (OpenAI "type": "file" format):

curl -X POST http://localhost:4000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer <LITELLM_KEY>" \
  -d '{
    "model": "mistral/mistral-small-latest",
    "messages": [{
      "role": "user",
      "content": [
        {
          "type": "file",
          "file": {
            "filename": "test.pdf",
            "file_data": "data:application/pdf;base64,<BASE64_PDF>"
          }
        },
        {"type": "text", "text": "What text does this PDF contain?"}
      ]
    }]
  }'

Result: HTTP 422 — Mistral receives the raw "type": "file" payload and rejects it:

MistralException - {"detail":[{"type":"string_type","loc":["body","messages",0,"user","content","str"],"msg":"Input should be a valid string"}]}

Expected behavior LiteLLM should translate "type": "file" to Mistral's native format:

{
  "type": "document_url",
  "document_url": "data:application/pdf;base64,<BASE64_PDF>"
}

This mapping is straightforward — the file_data data URI from the OpenAI format goes directly into the document_url field.

Verified working OpenAI via LiteLLM with "type": "file" → ✅ works (passthrough) Gemini via LiteLLM with "type": "file" → ✅ works (translated to inline_data) Mistral directly with "type": "document_url" → ✅ works (native format) Mistral via LiteLLM with "type": "file" → ❌ fails (not translated)

Relevant log output

What part of LiteLLM is this about?

Proxy

What LiteLLM version are you on ?

1.83.4

Twitter / LinkedIn details

No response

extent analysis

TL;DR

Update LiteLLM to translate "type": "file" content to "type": "document_url" for the Mistral provider.

Guidance

  • Verify that the issue is specific to the Mistral provider by testing other providers with the same "type": "file" content format.
  • Check the LiteLLM configuration for any existing translation rules for "type": "file" content and update them to include the Mistral provider.
  • Consider adding a custom translation rule for the Mistral provider to map "type": "file" to "type": "document_url".
  • Test the updated translation rule with a sample request to ensure it works as expected.

Example

{
  "type": "file",
  "file": {
    "filename": "test.pdf",
    "file_data": "data:application/pdf;base64,<BASE64_PDF>"
  }
}

should be translated to:

{
  "type": "document_url",
  "document_url": "data:application/pdf;base64,<BASE64_PDF>"
}

Notes

The issue seems to be specific to the Mistral provider and the "type": "file" content format. Updating the translation rule for this provider should fix the issue.

Recommendation

Apply a workaround by adding a custom translation rule for the Mistral provider to map "type": "file" to "type": "document_url", as the current version of LiteLLM (1.83.4) does not seem to support this translation out of the box.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#api#response parsing#generation error#database connection#vector store

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

litellm - ✅(Solved) Fix [Bug]: Mistral document file translation [1 pull requests, 1 comments, 2 participants]