LiteLLM silently uses application/octet-stream when file_uri MIME type cannot be determined

[YizukiAme]

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.

[surajksharma07]

@YizukiAme the debug-level fallback is definitely too quiet for something that silently breaks Vertex AI — that should at minimum be a warning, and the fail-fast ValueError approach in #5220 actually aligns better with what you described as expected behavior.

Also worth noting: the model propagation issue in recursive calls appears already fixed in v1.34.1+, so you may not be seeing that one depending on your version.

In the meantime, explicitly setting file_data.mime_type on your FileData is a reliable workaround — could you give that a try and confirm it holds for your GCS URI case?
Once you've validated, let us know whether #5207 or #5220 fits better and we can prioritize accordingly!

[surajksharma07]

Closing this out — the silent octet-stream fallback is actually gone as of v2.4.0, just landed via a different PR (#5023, fixing the duplicate #5022) rather than #5207 or #5220. file_data now raises a clear ValueError telling you to set file_data.mime_type explicitly instead of silently defaulting, so #5207 and #5220 are superseded and can probably be closed too.

Give v2.4.0 a spin and reopen if you're still hitting the silent fallback there!