From: andreas@rammhold.de
To: notmuch@notmuchmail.org
Subject: [RFC 0/2] add --new-tags= to notmuch-new(1)
Date: Thu, 16 Sep 2021 12:25:15 +0200 [thread overview]
Message-ID: <20210916102517.1744389-1-andreas@rammhold.de> (raw)
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
next reply other threads:[~2021-09-16 11:47 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-16 10:25 andreas [this message]
2021-09-16 10:25 ` [RFC 1/2] lib/config: introduce notmuch_config_values_from_string function andreas
2021-09-16 10:25 ` [RFC 2/2] CLI/notmuch: add --new-tags argument to notmuch-new(1) andreas
2021-09-16 12:03 ` [RFC 0/2] add --new-tags= " Michael J Gruber
2021-09-16 12:24 ` andreas
2021-09-16 14:43 ` Michael J Gruber
2021-09-20 23:57 ` David Bremner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://notmuchmail.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210916102517.1744389-1-andreas@rammhold.de \
--to=andreas@rammhold.de \
--cc=notmuch@notmuchmail.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://yhetil.org/notmuch.git/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).