Twine upload returns 409 Conflict after transient network timeout

Users need a way to recover from transient network interruptions during PyPI uploads while avoiding the creation of duplicate distribution files that would cause a 409 Conflict response. The legacy upload API used by twine accepts a file via POST and treats each attempt as a new upload, returning 409 if a file with the same name and version already exists.

Because twine does not perform automatic retries, it is unclear whether relying on surrounding automation to retry a failed POST will safely recover from timeouts or will inevitably resend the same file and provoke a duplicate‑file error. This raises questions about the existence of any built‑in retry logic, the recommended pattern for safe retries, and whether an idempotent upload endpoint or pre‑check could be used.

Does twine automatically retry a failed upload after a network timeout, or must retry logic be implemented externally? If external retries are necessary, what strategy prevents a second POST from triggering a 409 Conflict? Is there any plan or workaround to make PyPI uploads idempotent without changing the client?