From: Matt Armstrong <marmstrong@google.com>
To: notmuch@notmuchmail.org
Subject: A systematic way of handling Xapian lock errors?
User-Agent: Notmuch/0.21 (https://notmuchmail.org) Emacs/24.3.1
 (x86_64-pc-linux-gnu)
Date: Tue, 02 Aug 2016 08:26:43 -0700
Message-ID: <qf5d1lrkx8s.fsf@marmstrong-linux.kir.corp.google.com>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: list

Simple notmuch commands like "notmuch tag" can fail to grab the Xapian
lock.  When this occurs they bail with:

A Xapian exception occurred opening database: Unable to get write lock on /example/.notmuch/xapian: already locked

I've noticed a few issues with this:

1) The notmuch command line doesn't define semantics for exit codes.  I
notice that notmuch exits with 1 for "xapian write lock error".  I
suspect this code is not reserved for write lock errors?  That would be
needed for any sensible downgrade of the write lock error into a soft
failure with a retry loop in things like shell scripts.

2) The notmuch Emacs client just bails whatever it was trying when this
occurs.  I run background mail fetching, which I expect is typical, and
this makes for an unpleasant experience as errors are thrown at me
randomly.  Since my post-injection filter commands run quickly, I'd
rather Emacs simply spin a short while against the lock trying to
perform the command.  Even a one second spin attempt is likely to
succeed most of the time.  But I would happily configure an infinite
retry loop -- Emacs can show me a spinning ball, and I'd rather not be
subject to odd effects due to failures.

To address both, has something like this ever been considered:

  notmuch --lock_timeout <seconds> COMMAND ARG...

Then frontends like Emacs could lean on retry logic written in C.  If
this seems workable, it is something I can try implementing.