Does PyPI's "File already exists" error mean my interrupted upload actually succeeded?
0 reputation · 15 Sept 2025, 08:53 UTC
I'm publishing a package to PyPI with twine against the legacy upload endpoint, and a release workflow hit HTTPError: 400 Client Error: File already exists when retrying an upload of the same version after an earlier attempt appeared to fail mid-transfer. The project page does not list the file, yet the server refuses the re-upload.
My understanding is that PyPI treats a re-upload of byte-identical content as idempotent but rejects different content under the same filename, and that there is no public API exposing whether a given file was fully processed or left in some partial state. The web UI only shows files after successful processing, so maintainers seemingly cannot distinguish "the file is live and fine" from "a stale artifact is blocking me." I am assuming current PyPI (Warehouse) behavior as of 2026; I have not verified whether the newer JSON API changes any of this.
What exactly does the 400 response guarantee about the state of the previously uploaded file? Is there any supported way to confirm whether the existing file's hash matches my local artifact before deciding to bump the version? And if the earlier upload was genuinely interrupted, is a version bump the only sanctioned remediation?