Add support for delete and GET via file_id for gemini

[Sameerlite]

Relevant issues

Fixes #20054

Pre-Submission checklist

Please complete all items before asking a LiteLLM maintainer to review your PR

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

CI (LiteLLM team)

CI status guideline:

• 50-55 passing tests: main is stable with minor issues.
• 45-49 passing tests: acceptable but needs attention
• <= 40 passing tests: unstable; be careful with your merges and assess the risk.

• Branch creation CI run
  Link:

• CI run for the last commit
  Link:

• Merge / cherry-pick CI run
  Links:

Type

🆕 New Feature
🐛 Bug Fix
🧹 Refactoring
📖 Documentation
🚄 Infrastructure
✅ Test

Changes

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
litellm	Ready	Preview, Comment	Feb 3, 2026 1:30pm

[greptile-apps]

Greptile Overview

Greptile Summary

This PR adds support for deleting files using just the file ID (e.g., abc123) in addition to the full URI format. However, the implementation contains a critical bug where if file_id already includes the files/ prefix (e.g., files/abc123), the code will duplicate it to files/files/abc123, causing the delete operation to fail.

• Modified transform_delete_file_request to prepend files/ prefix for non-HTTP file IDs
• Bug: Does not check if files/ prefix already exists before adding it
• Should follow the same pattern as transform_retrieve_file_request which handles all three cases correctly (full URI, files/ prefix, bare ID)

Confidence Score: 2/5

• This PR is not safe to merge due to a logical bug that will cause failures when file_id includes the files/ prefix
• The implementation adds support for bare file IDs but introduces a critical bug where the files/ prefix is unconditionally added, creating duplicates like files/files/abc123 when the prefix already exists. This will break delete operations for any file_id that already has the prefix.
• litellm/llms/gemini/files/transformation.py requires the conditional check fix before merging

Important Files Changed

Filename	Overview
litellm/llms/gemini/files/transformation.py	Added support for bare file_id in delete, but introduced bug where files/ prefix gets duplicated if already present

Sequence Diagram

sequenceDiagram
    participant User
    participant LiteLLM
    participant GoogleAIStudio as Google AI Studio API
    
    Note over User,GoogleAIStudio: Delete File Flow
    
    User->>LiteLLM: delete_file(file_id)
    Note over LiteLLM: file_id can be:<br/>"abc123" OR<br/>"files/abc123" OR<br/>"https://.../files/abc123"
    
    LiteLLM->>LiteLLM: transform_delete_file_request()
    
    alt file_id starts with "http"
        LiteLLM->>LiteLLM: Extract path from full URI<br/>file_name = file_id.split("/v1beta/")[-1]
    else file_id is plain or prefixed
        LiteLLM->>LiteLLM: Add "files/" prefix<br/>file_name = f"files/{file_id}"
        Note over LiteLLM: ⚠️ BUG: If file_id already has "files/"<br/>prefix, this creates "files/files/..."
    end
    
    LiteLLM->>GoogleAIStudio: DELETE {api_base}/v1beta/{file_name}
    GoogleAIStudio-->>LiteLLM: 200 OK {}
    LiteLLM->>LiteLLM: transform_delete_file_response()
    LiteLLM-->>User: FileDeleted(id, deleted=True)

Loading

[greptile-apps]

_{1 file reviewed, 1 comment}

_{Edit Code Review Agent Settings | Greptile}

[greptile-apps]

this creates duplicate files/ prefix when file_id is already files/abc123, resulting in files/files/abc123

Suggested change

	file_name = f"files/{file_id}"
	file_name = file_id if file_id.startswith("files/") else f"files/{file_id}"

Prompt To Fix With AI

This is a comment left during a code review.
Path: litellm/llms/gemini/files/transformation.py
Line: 302:302

Comment:
this creates duplicate `files/` prefix when `file_id` is already `files/abc123`, resulting in `files/files/abc123`

```suggestion
            file_name = file_id if file_id.startswith("files/") else f"files/{file_id}"
```

How can I resolve this? If you propose a fix, please make it concise.

In general, the fix is to avoid treating the URL as an opaque string when validating its host or structure. Instead, the URL should be parsed using a standard URL parser (for example, urllib.parse.urlparse in Python), and assertions or checks should be made against structured components like scheme, netloc, and hostname. This prevents accidentally accepting URLs that merely contain an allowed host as a substring in an unsafe location.

For this specific test, we want to keep the existing intent—verifying that the constructed URL targets the Gemini API endpoint—but replace the substring assertion with a structured check on the parsed hostname. We will import urlparse from urllib.parse at the top of the file, and in test_transform_retrieve_file_request_with_file_name_only, we will replace assert "generativelanguage.googleapis.com" in url with code that parses url and asserts that parsed.hostname == "generativelanguage.googleapis.com". This keeps behavior equivalent (or stricter) while eliminating the substring-host pattern that CodeQL flags. No other test logic or functional behavior needs to change.

Concretely:

• Add from urllib.parse import urlparse alongside the existing imports in tests/test_litellm/llms/gemini/files/test_gemini_files_transformation.py.
• In test_transform_retrieve_file_request_with_file_name_only, replace the line at/around 63 with parsing url = ... and asserting on hostname. For example:
  • parsed_url = urlparse(url)
  • assert parsed_url.hostname == "generativelanguage.googleapis.com"
    This keeps the rest of the assertions (for file_id and API key presence, and empty params) unchanged.

In general, instead of checking that a trusted host appears as a substring of a URL, you should parse the URL and verify the hostname (and optionally scheme and path) explicitly. In Python, urllib.parse.urlparse provides a robust way to extract the hostname from a URL string and compare it against an expected value.

For this concrete test file, we only need to adjust the assertions that currently perform substring checks on the full URL. We can keep the behavior under test exactly the same (i.e., we don’t change GoogleAIStudioFilesHandler), but assert on parsed components instead of substring membership:

• In test_get_complete_url, replace assert api_base in url with a parse-based check that the URL’s scheme and hostname match the expected base, and that the path contains the expected upload endpoint.
• In test_transform_delete_file_request_with_full_uri, replace assert "generativelanguage.googleapis.com" in url with an assertion that urlparse(url).hostname == "generativelanguage.googleapis.com".
• In test_transform_delete_file_request_with_file_name_only, replace assert "generativelanguage.googleapis.com" in url with a similar hostname assertion, and replace assert file_id in url with a more specific path-based assertion.

To implement this, we need to:

• Import urlparse (or urllib.parse) at the top of tests/test_litellm/llms/gemini/files/test_gemini_files_transformation.py.
• Update the relevant assertions to use urlparse(url) and compare hostname and path.

No changes to production code are required, and there is no change in the intended behavior being tested; we are only tightening how the tests verify the domain and path.

In general, the problem with substring-based checks is that they do not ensure the host component of a URL is what you expect; the string can appear anywhere. The robust way to validate or assert URL structure is to parse the URL using a URL parser (such as urllib.parse.urlparse) and then inspect the specific components—scheme, netloc (host and port), path, and query parameters.

For this test, instead of asserting that "generativelanguage.googleapis.com" in url, we should parse url and assert that its netloc (or hostname) is exactly generativelanguage.googleapis.com. Similarly, for other structure-related checks (like assert file_id in url), we can tighten the test to assert on parsed.path.endswith(file_id) or similar, which still verifies the same behavior but with structured checks. Concretely:

• Add an import of urllib.parse.urlparse near the top of tests/test_litellm/llms/gemini/files/test_gemini_files_transformation.py.
• In test_transform_delete_file_request_with_full_uri, parse url and replace the existing host substring assertion with an assertion on parsed_url.netloc.
• In test_transform_delete_file_request_with_file_name_only, parse url and:
  • Replace assert file_id in url with an assertion based on parsed_url.path (e.g., endswith(file_id)).
  • Replace assert "generativelanguage.googleapis.com" in url with an assertion on parsed_url.netloc.

This preserves the intended checks (correct host and inclusion of file id in the URL) but removes reliance on unsafe substring matches.