I've recently became a little annoyed with a race condition in my current
notmuch setup that originates from only having a single set of new tags for
all notmuch-new(1) invocations. In the past I've mentioned this a couple of
times in the IRC channel and now I got around to implement a basic version of
this.

I rougly process new messages like this:

  1. new messages get the "new" tag through notmuch-new(1),
  2. the post-new hook calls a series of scripts
    a) all mails with the "new" tag are processed by [muchclassy] which
       is responsible for applying tags to all mails from mailing lists
       following the schema list::org.kernel.vger.linux-kernel.
    b) all mails with the "new" tag and a tag that matches
       /^list::com\.github\./ are passed through another script of mine
       that queries the GitHub API and attaches tags (gh::closed,
       gh::merged, ...) to the thread.
    c) a notmuch-tag(1) --batch script is executed on all new mails that
       filters out some nosiy senders, groups mailing lists, filters out
       closed/merged GitHub PRs, ... and adds "unread"/"inbox"/... tags to
       mails that I want to see in my default inbox query.
    d) finally the "new" tag is removed from all mails.

There are right now 8 mailboxes that I am retrieving mails from. I have a
scheduled job that updates all my local Maildir's every couple of minutes.
That one doesn't cause any issues on its own.

But I also use IMAP IDLE to selectively update Maildir's as soon as a new mail
arrives.

If I receive mails on multiple Maildir's within a short period of time the
above process is running into race-conditions since there is no way to
distinguish mails that have just been marked new. All of them carry the same
tags.

In the worst case one of the last steps (2c/2d) would pick up the new mail
before any of the actual classification has been executed. This "leaks" mails
into my inbox which consequently can be overwhelming to look at.

With this series I am able to give each notmuch-new(1) invocation a unique tag
(think: new-$(uuidgen)). This doesn't (on its own) solve the entire story but
is a first step in the "right direction" IMHO. I still have to wrap the entire
workflow to propagate the unique tag to all the sub-commands (via. e.g an
environment variable).

I am posting this as an RFC to see what other users and the developers think
about this approach and if anyone has solved a similar issue (in a different
way).

An alternative that I have considered is using a post-new hook that applies
the unique tag and removes the default new tags. This would probably work but
smells like a workaround / hack.

There are two FIXME's in the docstrings of the new
notmuch_config_values_from_string function as I didn't know what version this
would possible first available in.


Let me know what you think.


Andi


Andreas Rammhold (2):
  lib/config: introduce notmuch_config_values_from_string function
  CLI/notmuch: add --new-tags argument to notmuch-new(1)

 doc/man1/notmuch-new.rst |  7 +++++++
 lib/config.cc            | 12 +++++++++++-
 lib/notmuch.h            | 14 ++++++++++++++
 notmuch-new.c            | 16 +++++++++++++++-
 test/T050-new.sh         |  6 ++++++
 test/T590-libconfig.sh   | 22 ++++++++++++++++++++++
 6 files changed, 75 insertions(+), 2 deletions(-)

-- 
2.32.0
_______________________________________________
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-leave@notmuchmail.org