fix: fail fast when LiteLLM file_uri MIME type cannot be determined#5182
Open
YizukiAme wants to merge 1 commit intogoogle:mainfrom
Open
fix: fail fast when LiteLLM file_uri MIME type cannot be determined#5182YizukiAme wants to merge 1 commit intogoogle:mainfrom
YizukiAme wants to merge 1 commit intogoogle:mainfrom
Conversation
Signed-off-by: Yizuki_Ame <yinzimike@gmail.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #5184
Problem
When
file_data.file_urihas no explicit MIME type and the URI has no recognizable extension, the code silently falls back toapplication/octet-stream. This causes downstream issues with providers (e.g., Vertex AI) that require an accurate MIME type for GCS URIs — the generic fallback leads to incorrect file handling without any warning.Fix
application/octet-stream, raise aValueErrorwith a clear message suggesting the user setfile_data.mime_typeexplicitly. This only triggers when a file block actually needs to be constructed — provider-specific text fallback paths (e.g., Anthropic's[File reference: ...]) execute first and are unaffected._content_to_message_param()to passmodelthrough recursive calls for mixedfunction_response+ file content, preventing incorrect provider fallback on Vertex AI / Gemini._DEFAULT_MIME_TYPEconstant since the silent fallback is no longer used.Logs After Fix
Testing Plan
uv run pytest tests/unittests/models/test_litellm.py -v -k "file_uri or mime or function_response_with_extra_parts"All 42 related tests pass. Key coverage:
test_file_data_with_file_uri_no_mime_raises: VerifiesValueErrorwhen MIME cannot be determined and a file block is neededtest_file_data_with_file_uri_explicit_mime: Explicit MIME still workstest_file_data_with_file_uri_inferred_mime: Extension-based inference still workstest_function_response_with_extra_parts_preserves_model: Mixed content recursive calls now preservemodelparameter