# HG changeset patch
# User Matt Harbison <matt_harbison@yahoo.com>
# Date 1666285957 14400
# Node ID 250d9c8aaf108b2bd37688d2285be3c5a60d2923
# Parent  f68d285158b21d7d13c2a70c8db85e83a83ee392
lfs: improve an exception message for blob corruption detected on transfer

The message about the server crash originated in 0ee0a3f6a990 (after support for
serving blobs was added), but was copied from the Facebook repo that forked
prior to server side support.  Therefore, this message only displayed in their
client, so it was safe to assume the server crashed.  But that was never the
case for vanilla Mercurial, as I saw this in a server log.

Also, display the blob reference so that it's easier to figure out where the
problem was when a bunch of blobs are transferred at once.

diff -r f68d285158b2 -r 250d9c8aaf10 hgext/lfs/blobstore.py
--- a/hgext/lfs/blobstore.py	Mon Oct 24 17:35:30 2022 +0200
+++ b/hgext/lfs/blobstore.py	Thu Oct 20 13:12:37 2022 -0400
@@ -168,12 +168,16 @@
             # producing the response (but the server has no way of telling us
             # that), and we really don't need to try to write the response to
             # the localstore, because it's not going to match the expected.
+            # The server also uses this method to store data uploaded by the
+            # client, so if this happens on the server side, it's possible
+            # that the client crashed or an antivirus interfered with the
+            # upload.
             if content_length is not None and int(content_length) != size:
                 msg = (
                     b"Response length (%d) does not match Content-Length "
-                    b"header (%d): likely server-side crash"
+                    b"header (%d) for %s"
                 )
-                raise LfsRemoteError(_(msg) % (size, int(content_length)))
+                raise LfsRemoteError(_(msg) % (size, int(content_length), oid))
 
             realoid = hex(sha256.digest())
             if realoid != oid: