The second one fails because the initial write lock fails. I guess this is maybe a doc bug. --- test/T070-insert.sh | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+)
This is what I came up with when trying to induce indexing failure. The best I could do was make the initial notmuch open fail. This means my second test is broken. When I was writing the commit message I was thinking the man page was therefore wrong, but actually it's ok. I did wonder if it might be a good idea to move the database open after the message is written to disk, is we want to maximize the chance of insert --keep "succeeding". diff --git a/test/T070-insert.sh b/test/T070-insert.sh index aacc643..e7d0ae1 100755 --- a/test/T070-insert.sh +++ b/test/T070-insert.sh @@ -183,4 +183,25 @@ test_expect_code 1 "Invalid tags set exit code" \ notmuch config set new.tags $OLDCONFIG + +gen_insert_msg +test_python <<EOF & +import notmuch, time, os +with open("write-locker.pid","w") as pidfile: + pidfile.write(str(os.getpid())) +db = notmuch.Database(mode=notmuch.Database.MODE.READ_WRITE) +time.sleep(120) +EOF + +# give time for the background process to get started +sleep 1 + +test_expect_code 1 "Non-zero exit code due to write lock" \ + 'notmuch insert < "$gen_msg_filename" 2>&1' + +test_expect_code 0 "Zero exit code due to --keep flag" \ + 'notmuch insert --keep < "$gen_msg_filename" 2>&1' + +kill $(cat ${TMP_DIRECTORY}/write-locker.pid) >/dev/null 2>&1 + test_done -- 2.1.0