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
- Confirm the id is a LiteLLM unified file id (the one returned by the managed upload/list endpoints), not the raw provider id
- Treat 'not found' on delete as idempotent success in client code instead of surfacing an error
- 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
- Make deletes idempotent: check-then-delete or swallow not-found
- Only delete ids obtained from upload/list responses
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
- LiteLLM Managed {self.resource_type} with id={unified_resour
- Database not connected
- Setting tag based guardrail modes is only available in litel
- DB not connected. This endpoint needs a database; set DATABA
- You must be a LiteLLM Enterprise user to use this feature. I
AI-assisted analysis of BerriAI/litellm@6c2dcb801b (2026-08-15).
Data as JSON: /api/errors/ccd00809e21001a4.
Report an issue: GitHub.