Checked other resources

• This is a bug, not a usage question. For questions, please use GitHub Discussions.
• I added a very descriptive title to this issue.
• I searched the LangChain documentation and API reference with the integrated search.
• I used the GitHub search to find a similar question and didn't find it.
• I am sure that this is a bug in LangChain rather than my code.

Example Code

from langchain_core.messages import HumanMessage

# CSV attached via the OpenAI Chat Completions file block shape
# (same shape OpenAI docs prescribe for file inputs)
msg = HumanMessage(content=[
    {
        "type": "file",
        "file": {
            "filename": "sheet.csv",
            "file_data": "data:text/csv;base64,aGVsbG8=",
        },
    },
])

print(msg.content_blocks)

Error Message and Stack Trace (if applicable)

No exception. The output is:

[{'type': 'file', 'id': 'lc_...', 'base64': 'aGVsbG8=',
  'mime_type': 'application/pdf',   <-- silently wrong
  'extras': {'filename': 'sheet.csv'}}]

Description

In libs/core/langchain_core/messages/block_translators/openai.py, _convert_openai_format_to_data_block has two symmetrical base64 branches: one for images (image_url) and one for files.

The image branch correctly reads the MIME type from the parsed data URI:

# base64-style image block
if (block["type"] == "image_url") and (
    parsed := _parse_data_uri(block["image_url"]["url"])
):
    ...
    return types.create_image_block(
        base64=parsed["data"],
        mime_type=parsed["mime_type"],   # from data URI
        **all_extras,
    )

The file branch hard-codes PDF, discarding the parsed value:

# base64-style file block
if (block["type"] == "file") and (
    parsed := _parse_data_uri(block["file"]["file_data"])
):
    ...
    return types.create_file_block(
        base64=parsed["data"],
        mime_type="application/pdf",     # hard-coded
        filename=filename,
        **all_extras,
    )

Effect: any non-PDF file delivered via the OpenAI base64 file block shape (CSV, plain text, spreadsheets, office docs, etc.) is silently relabeled as application/pdf on the way into v1 content blocks. Since _normalize_messages calls this translator on every chat model's _astream, the wrong MIME type propagates to every downstream integration that consumes content_blocks.

_parse_data_uri already guarantees mime_type is non-empty whenever parsed is truthy (returns None otherwise), so the fix is a one-line change: use parsed["mime_type"] like the image branch does. No extra None check needed.

I've opened PR #36937 with the one-line fix and a regression test covering CSV and plain-text base64 file blocks. The PR was auto-closed for the missing-issue-link check. Happy to reopen once this issue is approved and assigned.

Found while tracing a separate production crash (PDF attachments through langchain-litellm to Anthropic-via-Vertex). This is a secondary correctness bug caught in passing.

System Info

langchain-core: master (reproduced on 1.2.7 as well) platform: macOS python version: 3.13