Mercurial push behavior when interrupted before server transaction commit

Mercurial’s push protocol is designed to avoid duplicate writes by checking existing changeset hashes before transferring data. However, the research notes that a network timeout can leave a hanging lock on the server and that large merges may cause client‑side failures before the transaction is finalized. The exact server‑side state after an interrupted push—whether any revlog data or transaction files remain and how they are handled on a subsequent retry—is not fully documented.

Understanding what Mercurial does with server‑side lock and transaction artifacts when a push is aborted mid‑transfer would clarify the safety of automatic retries and indicate whether manual cleanup is ever required.

Does the server automatically remove any .hg/transaction.* files and release the .hg/lock after a failed push?

If revlog data was partially written, does Mercurial roll back those changes or leave them as orphaned objects?

What observable state (e.g., lock file presence, transaction directory contents) can be inspected to confirm that a retry will not duplicate writes?