lfs: fix the stall and corruption issue when concurrently uploading blobs
We've avoided the issue up to this point by gating worker usage with an
experimental config. See 10e62d5efa73, and the thread linked there for some of
the initial diagnosis, but essentially some data was being read from the blob
before an error occurred and `keepalive` retried, but didn't rewind the file
pointer. So the leading data was lost from the blob on the server, and the
connection stalled, trying to send more data than available.
In trying to recreate this, I was unable to do so uploading from Windows to
CentOS 7. But it reproduced every time going from CentOS 7 to another CentOS 7
over https.
I found recent fixes in the FaceBook repo to address this[1][2]. The commit
message for the first is:
The KeepAlive HTTP implementation is bugged in it's retry logic, it supports
reading from a file pointer, but doesn't support rewinding of the seek cursor
when it performs a retry. So it can happen that an upload fails for whatever
reason and will then 'hang' on the retry event.
The sequence of events that get triggered are:
- Upload file A, goes OK. Keep-Alive caches connection.
- Upload file B, fails due to (for example) failing Keep-Alive, but LFS file
pointer has been consumed for the upload and fd has been closed.
- Retry for file B starts, sets the Content-Length properly to the expected
file size, but since file pointer has been consumed no data will be uploaded,
causing the server to wait for the uploaded data until either client or
server reaches a timeout, making it seem as our mercurial process hangs.
This is just a stop-gap measure to prevent this behavior from blocking Mercurial
(LFS has retry logic). A proper solutions need to be build on top of this
stop-gap measure: for upload from file pointers, we should support fseek() on
the interface. Since we expect to consume the whole file always anyways, this
should be safe. This way we can seek back to the beginning on a retry.
I ported those two patches, and it works. But I see that `url._sendfile()` does
a rewind on `httpsendfile` objects[3], so maybe it's better to keep this all in
one place and avoid a second seek. We may still want the first FaceBook patch
as extra protection for this problem in general. The other two uses of
`httpsendfile` are in the wire protocol to upload bundles, and to upload
largefiles. Neither of these appear to use a worker, and I'm not sure why
workers seem to trigger this, or if this could have happened without a worker.
Since `httpsendfile` already has a `close()` method, that is dropped. That
class also explicitly says there's no `__len__` attribute, so that is removed
too. The override for `read()` is necessary to avoid the progressbar usage per
file.
[1] https://github.com/facebookexperimental/eden/commit/c350d6536d90c044c837abdd3675185644481469
[2] https://github.com/facebookexperimental/eden/commit/77f0d3fd0415e81b63e317e457af9c55c46103ee
[3] https://www.mercurial-scm.org/repo/hg/file/5.2.2/mercurial/url.py#l176
Differential Revision: https://phab.mercurial-scm.org/D7962
test for old histedit issue #6:
editing a changeset without any actual change would corrupt the repository
$ . "$TESTDIR/histedit-helpers.sh"
$ cat >> $HGRCPATH <<EOF
> [extensions]
> histedit=
> EOF
$ initrepo ()
> {
> dir="$1"
> comment="$2"
> if [ -n "${comment}" ]; then
> echo % ${comment}
> echo % ${comment} | sed 's:.:-:g'
> fi
> hg init ${dir}
> cd ${dir}
> for x in a b c d e f ; do
> echo $x > $x
> hg add $x
> hg ci -m $x
> done
> cd ..
> }
$ geneditor ()
> {
> # generate an editor script for selecting changesets to be edited
> choice=$1 # changesets that should be edited (using sed line ranges)
> cat <<EOF | sed 's:^....::'
> # editing the rules, replacing 'pick' with 'edit' for the chosen lines
> sed '${choice}s:^pick:edit:' "\$1" > "\${1}.tmp"
> mv "\${1}.tmp" "\$1"
> # displaying the resulting rules, minus comments and empty lines
> sed '/^#/d;/^$/d;s:^:| :' "\$1" >&2
> EOF
> }
$ startediting ()
> {
> # begin an editing session
> choice="$1" # changesets that should be edited
> number="$2" # number of changesets considered (from tip)
> comment="$3"
> geneditor "${choice}" > edit.sh
> echo % start editing the history ${comment}
> HGEDITOR="sh ./edit.sh" hg histedit -- -${number} 2>&1 | fixbundle
> }
$ continueediting ()
> {
> # continue an edit already in progress
> editor="$1" # message editor when finalizing editing
> comment="$2"
> echo % finalize changeset editing ${comment}
> HGEDITOR=${editor} hg histedit --continue 2>&1 | fixbundle
> }
$ graphlog ()
> {
> comment="${1:-log}"
> echo % "${comment}"
> hg log -G --template '{rev} {node} \"{desc|firstline}\"\n'
> }
$ initrepo r1 "test editing with no change"
% test editing with no change
-----------------------------
$ cd r1
$ graphlog "log before editing"
% log before editing
@ 5 652413bf663ef2a641cab26574e46d5f5a64a55a "f"
|
o 4 e860deea161a2f77de56603b340ebbb4536308ae "e"
|
o 3 055a42cdd88768532f9cf79daa407fc8d138de9b "d"
|
o 2 177f92b773850b59254aa5e923436f921b55483b "c"
|
o 1 d2ae7f538514cd87c17547b0de4cea71fe1af9fb "b"
|
o 0 cb9a9f314b8b07ba71012fcdbc544b5a4d82ff5b "a"
$ startediting 2 3 "(not changing anything)" # edit the 2nd of 3 changesets
% start editing the history (not changing anything)
| pick 055a42cdd887 3 d
| edit e860deea161a 4 e
| pick 652413bf663e 5 f
0 files updated, 0 files merged, 2 files removed, 0 files unresolved
Editing (e860deea161a), you may commit or record as needed now.
(hg histedit --continue to resume)
$ continueediting true "(leaving commit message unaltered)"
% finalize changeset editing (leaving commit message unaltered)
check state of working copy
$ hg id
794fe033d0a0 tip
$ graphlog "log after history editing"
% log after history editing
@ 5 794fe033d0a030f8df77c5de945fca35c9181c30 "f"
|
o 4 04d2fab980779f332dec458cc944f28de8b43435 "e"
|
o 3 055a42cdd88768532f9cf79daa407fc8d138de9b "d"
|
o 2 177f92b773850b59254aa5e923436f921b55483b "c"
|
o 1 d2ae7f538514cd87c17547b0de4cea71fe1af9fb "b"
|
o 0 cb9a9f314b8b07ba71012fcdbc544b5a4d82ff5b "a"
$ cd ..
$ initrepo r2 "test editing with no change, then abort"
% test editing with no change, then abort
-----------------------------------------
$ cd r2
$ graphlog "log before editing"
% log before editing
@ 5 652413bf663ef2a641cab26574e46d5f5a64a55a "f"
|
o 4 e860deea161a2f77de56603b340ebbb4536308ae "e"
|
o 3 055a42cdd88768532f9cf79daa407fc8d138de9b "d"
|
o 2 177f92b773850b59254aa5e923436f921b55483b "c"
|
o 1 d2ae7f538514cd87c17547b0de4cea71fe1af9fb "b"
|
o 0 cb9a9f314b8b07ba71012fcdbc544b5a4d82ff5b "a"
$ startediting 1,2 3 "(not changing anything)" # edit the 1st two of 3 changesets
% start editing the history (not changing anything)
| edit 055a42cdd887 3 d
| edit e860deea161a 4 e
| pick 652413bf663e 5 f
0 files updated, 0 files merged, 3 files removed, 0 files unresolved
Editing (055a42cdd887), you may commit or record as needed now.
(hg histedit --continue to resume)
$ continueediting true "(leaving commit message unaltered)"
% finalize changeset editing (leaving commit message unaltered)
Editing (e860deea161a), you may commit or record as needed now.
(hg histedit --continue to resume)
$ graphlog "log after first edit"
% log after first edit
@ 6 e5ae3ca2f1ffdbd89ec41ebc273a231f7c3022f2 "d"
|
| o 5 652413bf663ef2a641cab26574e46d5f5a64a55a "f"
| |
| o 4 e860deea161a2f77de56603b340ebbb4536308ae "e"
| |
| o 3 055a42cdd88768532f9cf79daa407fc8d138de9b "d"
|/
o 2 177f92b773850b59254aa5e923436f921b55483b "c"
|
o 1 d2ae7f538514cd87c17547b0de4cea71fe1af9fb "b"
|
o 0 cb9a9f314b8b07ba71012fcdbc544b5a4d82ff5b "a"
abort editing session, after first forcibly updating away
$ hg up 0
abort: histedit in progress
(use 'hg histedit --continue' or 'hg histedit --abort')
[255]
$ mv .hg/histedit-state .hg/histedit-state-ignore
$ hg up 0
0 files updated, 0 files merged, 3 files removed, 0 files unresolved
$ mv .hg/histedit-state-ignore .hg/histedit-state
$ hg sum
parent: 0:cb9a9f314b8b
a
branch: default
commit: 1 added, 1 unknown (new branch head)
update: 6 new changesets (update)
phases: 7 draft
hist: 2 remaining (histedit --continue)
$ hg histedit --abort 2>&1 | fixbundle
modified files should survive the abort when we've moved away already
$ hg st
A e
? edit.sh
$ graphlog "log after abort"
% log after abort
o 5 652413bf663ef2a641cab26574e46d5f5a64a55a "f"
|
o 4 e860deea161a2f77de56603b340ebbb4536308ae "e"
|
o 3 055a42cdd88768532f9cf79daa407fc8d138de9b "d"
|
o 2 177f92b773850b59254aa5e923436f921b55483b "c"
|
o 1 d2ae7f538514cd87c17547b0de4cea71fe1af9fb "b"
|
@ 0 cb9a9f314b8b07ba71012fcdbc544b5a4d82ff5b "a"
aborting and not changing files can skip mentioning updating (no) files
$ hg up
5 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ hg commit --close-branch -m 'closebranch'
$ startediting 1 1 "(not changing anything)" # edit the 3rd of 3 changesets
% start editing the history (not changing anything)
| edit 292aec348d9e 6 closebranch
Editing (292aec348d9e), you may commit or record as needed now.
(hg histedit --continue to resume)
$ hg histedit --abort
$ cd ..