AI & Agent Dev Bug Sandbox logo
AI & Agent Dev Bug Sandbox
Back to Radar

Core: Converting A V0 Content Block That Carries An `Id` Raises TypeError

Accessing `content_blocks` on a HumanMessage containing legacy v0 content blocks with an `id` field raises `TypeError` because `_extract_v0_extras` leaks `id` into `**extras`, conflicting with the explicit `id=` argument.

highConfidence 95%LangChainAffected V1.6.0

Origin Analysis

In `langchain_core/messages/block_translators/langchain_v0.py`, the helper `_extract_v0_extras` returns every key not listed in `known_keys`. For URL and base64 branches of image/audio/file blocks, `known_keys` omits `"id"`, so if the input block carries an `id`, it remains in `extras`. Later, the code calls `types.create_image_block(..., id=block["id"], **extras)`, causing Python to pass the `id` keyword twice, raising `TypeError`. The three `source_type="id"` branches include `"id"` in `known_keys`, so only those work.
Run the following Python code: from langchain_core.messages import HumanMessage message = HumanMessage(content=[{"type": "image", "source_type": "url", "url": "https://example.com/x.png", "id": "block-1"}]) print(message.content_blocks) This raises TypeError: langchain_core.messages.content.create_image_block() got multiple values for keyword argument 'id'.

Fixing Code Block

Edge Case Audit

The helper is private but used internally across all v0 block conversion branches. Excluding 'id' is safe because no caller currently relies on 'id' appearing in extras: URL/base64 branches pass it explicitly, and source_type='id' branches already consume it as known_keys. However, if any future external code imported _extract_v0_extras and expected 'id' in extras, it would see a change (though such code would already break due to the TypeError). Rollback is trivial if unexpected regressions appear; run the langchain-core unit suite and the newly added tests before release.

Ecosystem Topology