To git-annex-test and git-annex-testremote, add option to run tests under concurrency (-J). Many possible bugs are unique to the concurrent case, and it's the case I often use. While any bugs detected may be hard to reproduce, it's important to know whether there are concurrency-related bugs. Much of the trust in git-annex comes from its extensive test suite, but it's somewhat concerning to trust it with important data when the concurrency case is not tested at all.
As the test suite is constructed, there is a single origin repository shared by clones used for each test case, and there are test cases that do eg
git annex move --from origin ; git annex move --to originand so would break other tests cases using the same origin if they were run concurrently, without it being an actual concurrency bug in git-annex.So parallelizing the test suite would need each test case to have its own isolated set of test repos. But then concurrency bugs could not be found by the test suite; concurrency would only possibly make it run faster.
Finding concurrency bugs seems to need the test repos to contain more files than the two or three they now do, so that a single test case can run some git-annex operation concurrently on several files at once.
Also, if you look at the CHANGELOG, you'll find that concurrency bugs in git-annex beyond the UI level are fairly rare. And I can think of only one concurrency bug that ever caused even theoretical data loss; it involved 3 repos in a triangle topology all dropping the same file at the same time.
"Finding concurrency bugs seems to need the test repos to contain more files than the two or three" -- it should be enough to run a concurrent operation many times on a small repo. This will test the different possible orders of operation. Most concurrency bugs only involve a conflict of two or three operations.
Running under something like https://rr-project.org/ can be used to reliably reproduce concurrency bugs.
"I can think of only one concurrency bug that ever caused even theoretical data loss" -- that's good. But beyond data loss, when a complex operation fails in the middle, it can be non-trivial to figure out which parts to redo.