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

  1. Check the gateway log for the 'Failed to delete' error line — the {str(e)} names the exact errno/cause.
  2. Fix ownership/permissions on the thread uploads directory so the gateway user can unlink.
  3. 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

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


AI-assisted analysis of bytedance/deer-flow@1dd6ba1acb (2026-08-14). Data as JSON: /api/errors/4f5cc5b85be01182. Report an issue: GitHub.