BerriAI/litellm · error · Exception

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

Error message

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

What it means

Generic Exception raised by ManagedFiles.delete_unified_file_id: a find_first on the managed-file table by unified_file_id returned None, so there is nothing to delete. The file id supplied does not exist (or was already deleted / belongs to a different object type).

Source

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

        )

        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 6c2dcb801b)

Solutions

  1. Confirm the id is a LiteLLM unified file id (the one returned by the managed upload/list endpoints), not the raw provider id
  2. Treat 'not found' on delete as idempotent success in client code instead of surfacing an error
  3. List files for the owner first (list endpoint) and delete using an id from that result

Example fix

# before
await managed_files.delete_unified_file_id(file_id)  # may raise

# after
existing = await managed_files.get_file_by_unified_id(file_id)
if existing is None:
    return  # already deleted / never existed
await managed_files.delete_unified_file_id(file_id)
Defensive patterns

Strategy: type-guard

Validate before calling

existing = await managed_files.get_file_by_unified_id(file_id)
if existing is None:
    return {'deleted': False}  # idempotent no-op

Type guard

async def file_exists(mf, file_id: str) -> bool:
    return await mf.get_file_by_unified_id(file_id) is not None

Try / catch

try:
    await managed_files.delete_unified_file_id(file_id)
except Exception as e:
    if 'not found' in str(e):
        return  # already gone; treat delete as idempotent
    raise

Prevention

When it happens

Trigger: DELETE on a managed file whose unified_file_id is absent from the managed files table: retrying a delete that already succeeded, an id from a different environment, or passing a plain OpenAI file id where a LiteLLM unified id is expected.

Common situations: Client retry logic re-sending a successful delete without idempotency handling; id mismatch between provider file ids and LiteLLM unified ids when managed files/batches are enabled; concurrent deletion by another request or admin.

Related errors


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