Re: [RFC 0/2] add --new-tags= to notmuch-new(1)

[Michael J Gruber <git@grubix.eu>]

andreas@rammhold.de venit, vidit, dixit 2021-09-16 12:25:15:
> 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
...
> 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

I very much sympathize with your setup. But I think the real solution
would be one of these options:

- use a lock file to prevent your scripts from running concurrently OR

- match "tag:new and folder:UNIQUEFOLDER" (or "path:FOO/**")
  This should be a perfect substitute for your new-UNIQUE tag.

As for the implementation you suggest: Basically, you implement
overriding the "new.tags" config, and I'm wondering whether it would be
worthwhile to implement "notmuch --config-value" instead:

--config-value=SECTION.ITEM=VALUE
	Override the config setting for SECTION.ITEM with the VALUE for
	this invocation. This takes precedence over any setting in the
	config file.

I know this raises the question which config any hooks will see, but
that is the same for your implementation.

You can override the complete config by specifying a different file
already, of course, so you could script that.

Cheers
Michael