[Anish Mehta (anishmehta24)]

Motivation and Context

Content.from_dict pops the three shared fields off the mapping before dispatching:

annotations = remaining.pop("annotations", None)
additional_properties = remaining.pop("additional_properties", None)
raw_representation = remaining.pop("raw_representation", None)

then hands them to the constructor at the bottom. But the data case returns before ever reaching it:

if content_type == "data" and "data" in remaining and "media_type" in remaining:
    return cls.from_data(remaining["data"], remaining["media_type"])

from_data accepts annotations, additional_properties and raw_representation as keyword arguments — they just weren't being passed. So a data content silently lost all three, while every other content type kept them:

Content.from_dict({"type": "data", "data": b"hello", "media_type": "text/plain",
                   "additional_properties": {"origin": "upload"},
                   "raw_representation": "provider-blob"})
# additional_properties == {}     raw_representation is None     annotations is None

Content.from_dict({"type": "uri", "uri": "https://example.com/x.png",
                   "media_type": "image/png",
                   "additional_properties": {"origin": "upload"},
                   "raw_representation": "provider-blob"})
# both preserved

This isn't only a direct-call concern. Content.from_dict is what Message.from_dict, ChatResponse.from_dict and ChatResponseUpdate.from_dict use to rebuild contents, so restoring a stored conversation dropped the metadata on any data content it held, with nothing to indicate it.

Worth noting it doesn't show up in a plain round trip, which is probably why it survived: to_dict() on a data content emits uri rather than data, so from_dict(to_dict(c)) never takes this branch. It's the hand-built or provider-supplied data + media_type mapping — the shape this branch exists to support — that loses the fields.

Description

Pass the three popped fields to from_data. One call, no signature change, no new behaviour — the special case now keeps what the general case already kept.

One thing I left alone: this branch requires data to be bytes and raises TypeError on a base64 string. That looks deliberate — from_data's docstring says "If you have a base64 string, decode it first" — so I didn't touch it, though it does mean the branch can't consume a mapping that came from JSON. Happy to look at that separately if it's worth changing.

Contribution Checklist

• The code builds clean without any errors or warnings
• I didn't break anyone 😄

Tests in packages/core/tests/core/test_types.py:

• test_content_from_dict_data_keeps_annotations_and_metadata — all three survive
• test_content_from_dict_data_matches_other_types_on_metadata — a data content and a uri content built from the same shape are treated the same
• test_message_from_dict_keeps_data_content_metadata — the reachable path, through Message.from_dict

All three fail on main. tests/core/test_types.py passes in full and the whole tests/core directory is green. ruff check and ruff format clean.

🤖 Generated with Claude Code

https://claude.ai/code/session_01WyCUJcDPnCnQMmuDwsnDmD

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[Eduard van Valkenburg (eavanvalkenburg)]

Anish Mehta (@anishmehta24) The current head is green, and the dedicated full-diff review found no remaining actionable issues with preserving annotations and metadata when Content.from_dict constructs data content.