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.