fix: raise ValueError for unsupported MIME types in file_data URI path

[Raman369AI]

Fixes #5022

Problem

When a Part with file_data.file_uri has no determinable MIME type, the library fell back to application/octet-stream via _DEFAULT_MIME_TYPE. This value then propagated to LiteLLM which raised a cryptic internal ValueError with no guidance for the user.

The same failure occurred when the caller explicitly set mime_type = "application/octet-stream" on the Part. Both cases reach the same failure point.

There was also an inconsistency between the two content paths:

• The inline_data path raises ValueError immediately for unsupported MIME types
• The file_data path silently used a fallback and failed later with a cryptic message

GcsArtifactService generates URIs like gs://bucket/artifact/0 with no extension and no MIME type, making ADK's own artifact system the primary trigger for this fallback.

Fix

Removes _DEFAULT_MIME_TYPE and raises ValueError early with an actionable message when the resolved MIME type is either unknown or application/octet-stream. This aligns the file_data path with the existing fail-fast behavior of the inline_data path.

The logic order is also corrected so providers that always produce a text fallback (anthropic, non-Gemini Vertex AI) and OpenAI/Azure HTTP media URLs are handled before the MIME type guard, keeping those paths unaffected.

Changes

• src/google/adk/models/lite_llm.py: remove _DEFAULT_MIME_TYPE, restructure file_uri handling block, raise ValueError for missing or generic MIME types
• tests/unittests/models/test_litellm.py: update two existing tests to assert the new ValueError, add one new test covering explicit application/octet-stream

Testing

pytest tests/unittests/models/test_litellm.py
241 passed, 5 errors (pre-existing, missing pytest-mock fixture)

Format verified with pyink. mypy error count unchanged from main (26).

[rohityan]

Hi @Raman369AI , Thank you for your contribution! We appreciate you taking the time to submit this pull request. Your PR has been received by the team and is currently under review. We will provide feedback as soon as we have an update to share.

[rohityan]

Hi @wukath, can you please review this.

[Raman369AI]

@Raman369AI
One thing to confirm before this is merge-ready: do the unit tests exercise both branches —
(1) a file_uri with no inferrable MIME type where resolution falls through to None, and
(2) an explicit mime_type="application/octet-stream" passed in by an upstream caller?

Following up on @surajksharma07's review — yes, both branches are now covered.

Introduced test_content_to_message_param_user_message_file_uri_explicit_octet_stream to exercise branch (2) at the _content_to_message_param level, alongside the existing tests that covered branch (1). All four relevant tests pass:

Branch (1) — MIME resolves to None:

• test_content_to_message_param_user_message_file_uri_without_mime_type
• test_get_content_file_uri_default_mime_type

Branch (2) — explicit application/octet-stream from caller:

• test_content_to_message_param_user_message_file_uri_explicit_octet_stream (new)
• test_get_content_file_uri_explicit_octet_stream_raises

============================= test session starts ==============================
platform linux -- Python 3.12.3, pytest-9.0.2, pluggy-1.6.0

collected 247 items / 243 deselected / 4 selected

tests/unittests/models/test_litellm.py::test_content_to_message_param_user_message_file_uri_without_mime_type PASSED [ 25%]
tests/unittests/models/test_litellm.py::test_content_to_message_param_user_message_file_uri_explicit_octet_stream PASSED [ 50%]
tests/unittests/models/test_litellm.py::test_get_content_file_uri_default_mime_type PASSED [ 75%]
tests/unittests/models/test_litellm.py::test_get_content_file_uri_explicit_octet_stream_raises PASSED [100%]

====================== 4 passed, 243 deselected in 2.43s =======================