PR #26228: fix(anthropic): skip non-OpenAI file content blocks in file-id discovery helpers

• Repository: BerriAI/litellm
• Author: anmolg1997
• State: closed | merged: True
• Link: https://github.com/BerriAI/litellm/pull/26228

Description (problem / solution / changelog)

Relevant issues

Closes #26227. Related to #24503 (different approach, see below).

Pre-Submission checklist

• I have Added testing in the tests/test_litellm/ directory, Adding at least 1 test is a hard requirement
• My PR passes all unit tests on make test-unit for the affected module
• My PR's scope is as isolated as possible, it only solves 1 specific problem

Type

Bug Fix

Problem

AnthropicConfig.validate_environment (run on every Anthropic + Anthropic-via-Vertex request) calls:

• is_file_id_used -> get_file_ids_from_messages (common_utils.py:1049)
• downstream also update_messages_with_model_file_ids (common_utils.py:431)

Both helpers short-circuit on c[\"type\"] == \"file\" and then do a bare c[\"file\"] access. Any content block that uses \"file\" as its type discriminator but does not match the OpenAI Chat Completions sub-shape (nested file dict) raises KeyError: 'file'. The Vertex partner layer wraps this as VertexAIError(500) -> litellm.InternalServerError, before the LLM is contacted.

Real-world trigger: LangChain v1's _normalize_messages rewrites OpenAI file blocks into {\"type\":\"file\",\"id\":...,\"base64\":...,\"mime_type\":...,\"extras\":{}} on the way into every chat model. Hits every vertex_ai/claude-* and anthropic/claude-* request that carries an attachment.

See #26227 for full RCA, traceback, and minimal repro.

Fix

type: \"file\" is a public content-block discriminator. The two helpers above are discovery passes:

• get_file_ids_from_messages returns a list of file IDs.
• update_messages_with_model_file_ids rewrites provider-scoped file IDs in-place.

A block with no file sub-dict has no file_id to extract or remap, so the correct behavior is to skip the block, not raise. This patch switches both from c[\"file\"] to c.get(\"file\") + isinstance(..., dict) check, and continues past non-OpenAI blocks.

Why skip and not raise BadRequestError (as in #24503)

PR #24503 raises BadRequestError in these two spots. For the stricter sites it also touches (Gemini/Bedrock/Anthropic transformers, migrate_file_to_image_url), that is the right behavior: a block that has reached the provider transformer is expected to be fully-formed OpenAI shape, and a missing file sub-dict really is a malformed request.

These two discovery helpers are different. They run unconditionally inside validate_environment, ahead of any provider-specific transformer. Raising BadRequestError here fails the whole request for any legitimate non-OpenAI block (LangChain v1, provider-native, custom user shapes) even when the downstream transformer would handle it correctly. Skip is strictly more permissive: well-formed OpenAI blocks still yield their file_id, and non-OpenAI blocks stop crashing validate_environment.

Happy to coordinate with @krisxia0506 if this should land as a delta on top of #24503, or get rolled in there directly.

Changes

Tests

All 25 tests in test_litellm_core_utils_prompt_templates_common_utils.py pass locally:

======================== 25 passed, 2 warnings in 0.40s ========================

New tests cover:

• test_get_file_ids_from_messages_skips_langchain_v1_file_block
• test_get_file_ids_from_messages_still_extracts_from_openai_shape
• test_get_file_ids_from_messages_mixed_shapes
• test_get_file_ids_from_messages_file_field_not_dict
• test_update_messages_with_model_file_ids_skips_non_openai_file_blocks

Changed files

• litellm/litellm_core_utils/prompt_templates/common_utils.py (modified, +14/-2)
• tests/test_litellm/litellm_core_utils/prompt_templates/test_litellm_core_utils_prompt_templates_common_utils.py (modified, +113/-0)