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 _______________________________________________ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-leave@notmuchmail.org