#40424 core: content_blocks raises TypeError on a v0 multimodal block that carries an id

Submission checklist

This is a bug, not a usage question.
I added a clear and descriptive title that summarizes this issue.
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.
The bug is not resolved by updating to the latest stable version of LangChain (or the specific integration package).
This is not related to the langchain-community package.
I posted a self-contained, minimal, reproducible example. A maintainer can copy it and run it AS IS.

Package (Required)

langchain
langchain-openai
langchain-anthropic
langchain-classic
langchain-core
langchain-model-profiles
langchain-tests
langchain-text-splitters
langchain-chroma
langchain-deepseek
langchain-exa
langchain-fireworks
langchain-groq
langchain-huggingface
langchain-mistralai
langchain-nomic
langchain-ollama
langchain-openrouter
langchain-perplexity
langchain-qdrant
langchain-xai
Other / not sure / general

Related Issues / PRs

None found. I searched the open issues and the 93 open pull requests: nothing mentions this, and no open PR touches langchain_core/messages/block_translators/langchain_v0.py.

Reproduction Steps / Example Code (Python)

from langchain_core.messages import HumanMessage

message = HumanMessage(
    content=[
        {
            "type": "image",
            "source_type": "url",
            "url": "https://example.com/image.png",
            "id": "block-1",
        }
    ]
)

message.content_blocks

Error Message and Stack Trace (if applicable)

TypeError: langchain_core.messages.content.create_image_block() got multiple values for keyword argument 'id'

Description

Reading content_blocks on a legacy v0 multimodal block that carries an id raises TypeError instead of returning the block.

_convert_legacy_v0_content_block_to_v1 builds extras from every key of the source block that is not in known_keys. For the url, base64 and text source types, known_keys leaves out id, so id stays in extras and reaches the constructor twice: once as id=block["id"], once through **extras.

The consequence is that the if "id" in block: branch can never succeed. It raises on every input that reaches it, so the code written to carry the original id across the v0 to v1 conversion has never been able to run. The source_type: "id" branches already list id in known_keys, which is why they behave correctly and made the omission easy to miss.

Seven branches are affected: image/url, image/base64, audio/url, audio/base64, file/url, file/base64 and file/text. I checked each one, all seven raise.

The fix is to add id to known_keys in those seven branches. When a block has no id, extras cannot contain one, so the path that builds a block without an id is unchanged; the only behaviour that changes is a branch that could previously only raise.

I have the change and a parametrized regression test covering the seven branches ready on a branch, in case it helps: https://github.com/langchain-ai/langchain/compare/master...Dev-next-gen:langchain:leoca/core/v0-multimodal-block-id

With the fix reverted and the tests kept, the suite reports 8 failed, 2 passed; with the fix, 10 passed. ruff check, ruff format --check and mypy on the changed module are clean.

I would be glad to open the pull request if a maintainer agrees with the approach and assigns this issue to me.

This report was prepared with the help of an AI coding agent; I reviewed every line and ran the tests locally.

System Info

System Information

OS: Windows OS Version: 10.0.26200 Python Version: 3.12.9 (tags/v3.12.9:fdb8142, Feb 4 2025, 15:27:58) [MSC v.1942 64 bit (AMD64)]

Package Information

langchain_core: 1.6.3 langsmith: 0.12.4 langchain_protocol: 0.0.19 langchain_tests: 1.1.9

Social handles (optional)

No response