BerriAI/litellm · error · Exception

LiteLLM Managed File object with id=

Error message

LiteLLM Managed File object with id={file_id} not found

What it means

Raised as a plain Exception (500 at the HTTP layer) by ManagedFilesHook.delete_unified_file_id when no row matches the given unified_file_id in the managed file table. The delete path first fetches the row to return its file_object payload; if the find_first returns None - id typo'd, already deleted, or never created through the managed-files API - it fails with this message instead of deleting silently.

Solutions

  1. List managed files for the user first and delete using the exact unified_file_id from the listing
  2. Treat a repeated delete as idempotent success if your workflow allows it (catch the 'not found' message)
  3. Confirm you are on the same proxy/database where the file was created
  4. Ensure you pass the unified (base64-encoded) id returned at creation time, not the provider-side file id

Example fix

# before
await managed_files_hook.delete_unified_file_id(file_id)  # Exception if already gone
# after
if await managed_files_hook.get_managed_file(file_id) is not None:
    await managed_files_hook.delete_unified_file_id(file_id)
Defensive patterns

Strategy: validation

Validate before calling

# Idempotent delete: only call delete when the row exists
existing = await _managed_file_table(prisma).find_first(where={"unified_file_id": file_id})
if existing is None:
    return existing  # nothing to do (or raise your own NotFound)

Try / catch

try:
    obj = await hook.delete_unified_file_id(file_id)
except Exception as e:
    if "not found" in str(e):
        return  # treat repeated delete as success
    raise

Prevention

When it happens

Trigger: Calling the managed files delete endpoint twice (second call finds nothing); deleting a unified file id from a different proxy/database; passing the raw provider file id instead of the base64-encoded unified id; the row was removed by a concurrent request or team member.

Common situations: Retry logic in client code re-sends a delete after a timeout even though the first delete succeeded; id confusion between provider file ids (file-abc123) and unified ids (base64 blob); environment mismatch between where the file was uploaded and where deletion is attempted.

Understand the failure class

Background: 'Could not be found', 'does not exist', 'not found in database': the resource-not-found family when an ID, slug, key, or URI lookup comes back empty — this error's family across 20 libraries.

Related errors

AI-assisted analysis of BerriAI/litellm@77b7c6c40c (2026-08-18). Data as JSON: /api/errors/ccd00809e21001a4. Report an issue: GitHub.

Appendix: source

Thrown at enterprise/litellm_enterprise/proxy/hooks/managed_files.py:372

        )

        if result:
            return LiteLLM_ManagedFileTable.model_validate(result)

        ## CHECK DB
        db_object = await _managed_file_table(self.prisma_client).find_first(where={"unified_file_id": file_id})

        if db_object:
            return LiteLLM_ManagedFileTable.model_validate(db_object.model_dump())
        return None

    async def delete_unified_file_id(
        self, file_id: str, litellm_parent_otel_span: Optional[Span] = None
    ) -> OpenAIFileObject:
        ## get old value
        initial_value = await _managed_file_table(self.prisma_client).find_first(where={"unified_file_id": file_id})
        if initial_value is None:
            raise Exception(f"LiteLLM Managed File object with id={file_id} not found")
        ## delete old value
        await self.internal_usage_cache.async_set_cache(
            key=file_id,
            value=None,
            litellm_parent_otel_span=litellm_parent_otel_span,
        )
        await _managed_file_table(self.prisma_client).delete(where={"unified_file_id": file_id})
        return initial_value.file_object

    async def can_user_call_unified_file_id(self, unified_file_id: str, user_api_key_dict: UserAPIKeyAuth) -> bool:
        managed_file = await _managed_file_table(self.prisma_client).find_first(
            where={"unified_file_id": unified_file_id}
        )

        if managed_file:
            return can_access_resource(
                user_api_key_dict=user_api_key_dict,
                created_by=managed_file.created_by,

View on GitHub (pinned to 77b7c6c40c)