bytedance/deer-flow · error · HTTPException
Failed to delete {filename}: {str(e)}
Error message
Failed to delete {filename}: {str(e)} What it means
HTTP 500 raised by DELETE /threads/{thread_id}/uploads/{filename} for any unexpected exception during deletion (permissions, I/O errors, filesystem corruption). The original exception text is included in the detail and logged as 'Failed to delete <filename>'. Unlike the 404/400 branches, this indicates a server-side environment problem.
Source
Thrown at backend/app/gateway/routers/uploads.py:483
return UploadListResponse(**result)
@router.delete("/{filename}")
@require_permission("threads", "delete", owner_check=True, require_existing=True)
async def delete_uploaded_file(thread_id: ThreadId, filename: str, request: Request) -> dict:
"""Delete a file from a thread's uploads directory."""
try:
return await run_file_io(_delete_uploaded_file_for_thread, thread_id, filename, get_effective_user_id())
except FileNotFoundError:
raise HTTPException(status_code=404, detail=f"File not found: {filename}")
except PathTraversalError:
raise HTTPException(status_code=400, detail="Invalid path")
except ValueError as e:
raise HTTPException(status_code=400, detail=str(e))
except Exception as e:
logger.error(f"Failed to delete {filename}: {e}")
raise HTTPException(status_code=500, detail=f"Failed to delete {filename}: {str(e)}")
View on GitHub (pinned to 1dd6ba1acb)
Solutions
- Check the gateway log for the 'Failed to delete' error line — the {str(e)} names the exact errno/cause.
- Fix ownership/permissions on the thread uploads directory so the gateway user can unlink.
- If the volume is flaky (NFS), remount or move uploads to local storage, then retry.
Defensive patterns
Strategy: try-catch
Try / catch
catch 500 on delete; inspect detail for errno; surface to operator — retrying without fixing permissions/disk will fail identically.
Prevention
- Run the gateway under a stable uid and chown the uploads volume to match.
- Prefer local volumes over NFS/FUSE for uploads storage.
- Include an unlink permission check in deployment smoke tests.
When it happens
Trigger: OSError removing the file: EACCES (wrong ownership, e.g. root-owned file after a container switch), EBUSY (file locked), EXDEV/io errors from a failing volume.
Common situations: Uploads volume permission drift after running the gateway as different users; NFS/FUSE mounts with unreliable unlink; files created by the sandbox process with restrictive modes.
Related errors
- Failed to delete local thread data.
- Failed to upload {file.filename}: {str(e)}
- Failed to delete file
- Failed to list agents: {str(e)}
- Failed to get agent: {str(e)}
AI-assisted analysis of bytedance/deer-flow@1dd6ba1acb (2026-08-14).
Data as JSON: /api/errors/4f5cc5b85be01182.
Report an issue: GitHub.