Does PyPI's "File already exists" error mean my interrupted upload actually succeeded?

Short answer

No — the 400 does not tell you the earlier upload succeeded. It only guarantees that PyPI has already registered a file with that exact filename (project, version, and distribution tag) in its database. Whether the stored bytes are complete, corrupt, or simply different from what you're now sending is something the error alone cannot tell you.

What the 400 actually means

PyPI's legacy upload endpoint historically treats a re-upload of byte-identical content under an existing filename as an idempotent no-op, while rejecting different content under the same filename with 400. So a 400 on retry suggests one of two things:

• The earlier upload completed, but your local rebuild produced different bytes (wheels often embed timestamps, so rebuilding the same source can yield a different digest).
• The earlier attempt was interrupted mid-transfer and left a registered filename without a fully processed, visible file — the edge case you're worried about.

There is no supported API to inspect a partially processed upload, so you cannot directly distinguish these server-side. What you can do is check whether a fully processed file exists.

How to check the existing file's hash

If the file was fully processed, it is served and its SHA-256 is published in the JSON API. Compare it against your local artifact:

sha256sum dist/mypkg-1.2.3-py3-none-any.whl
# then fetch:
# https://pypi.org/pypi/mypkg/1.2.3/json
# inspect urls[].filename and urls[].digests.sha256

Decision rule:

1. Hash present and matches — your file is live and fine; the retry was unnecessary. Do nothing.
2. Hash present but differs — the earlier upload succeeded with different bytes; your local build is not reproducible. You cannot replace the file.
3. File absent from the JSON API and project page, yet uploads still 400 — likely a failed transaction left a registered filename without a visible file. Self-service recovery is limited here.

Is a version bump the only fix?

For cases 2 and 3, effectively yes. PyPI does not allow replacing or deleting an uploaded file, and deleting the release in the web UI does not free the filename. The sanctioned remediation is a new version — and a post-release (1.2.3.post1) exists precisely for re-releasing without a code change. For case 3 specifically, you can also file an issue on the PyPI support tracker, but a post-release bump is usually faster.

Caveats

This reflects well-established Warehouse behavior as of 2026; exact idempotency semantics of the legacy endpoint are version-sensitive and worth verifying against current PyPI documentation before relying on them in automation. The JSON API digest check above is the most reliable confirmation available today.