Bug Description
When file_data.file_uri has no explicit MIME type and the URI has no recognizable file extension, the LiteLLM integration silently falls back to application/octet-stream via _DEFAULT_MIME_TYPE. This causes incorrect file handling with providers that validate MIME types (e.g., Vertex AI for GCS URIs) without any warning to the developer.
Additionally, _content_to_message_param() does not propagate the model parameter in recursive calls for mixed function_response + file content, causing incorrect provider detection on Vertex AI / Gemini.
Steps to Reproduce
# A file_uri with no extension and no explicit MIME type
part = types.Part(file_data=types.FileData(
file_uri="gs://bucket/artifact/0"
# mime_type not set, no extension to infer from
))
# Result: silently uses "application/octet-stream"
# On Vertex AI, this leads to incorrect file handling
Expected Behavior
- A clear error should be raised when MIME cannot be determined and a file block needs to be constructed, with guidance to set
file_data.mime_type explicitly
- Provider-specific text fallback paths should still work without requiring MIME
Actual Behavior
Silent fallback to application/octet-stream with a debug-level log that's easy to miss.
Bug Description
When
file_data.file_urihas no explicit MIME type and the URI has no recognizable file extension, the LiteLLM integration silently falls back toapplication/octet-streamvia_DEFAULT_MIME_TYPE. This causes incorrect file handling with providers that validate MIME types (e.g., Vertex AI for GCS URIs) without any warning to the developer.Additionally,
_content_to_message_param()does not propagate themodelparameter in recursive calls for mixedfunction_response+ file content, causing incorrect provider detection on Vertex AI / Gemini.Steps to Reproduce
Expected Behavior
file_data.mime_typeexplicitlyActual Behavior
Silent fallback to
application/octet-streamwith adebug-level log that's easy to miss.