Hi >> Do you have a particular use case where indexing is required but tagging >> is not? For my uses I would prefer failing if either indexing or tagging >> failed. (My use being postponing messages; If they don't get the >> postponed tag they could be hard to find) > > You're right. > > What about a failure to sync tags to maildir flags? Personally, I wouldn't mind ignoring this failure: it should be relatively easy to fix after the fact (but others may disagree). > I now noticed that database modifications aren't flushed until the > notmuch_database_destroy call (right?), which has no return value and > failure of which is silently ignored. That's acceptable in the default > mode, but with --must-index the failure should be reported (and the > file deleted). Yes I think you are right: flushed by notmuch_database_close which is called by notmuch_database_destroy. Perhaps the easiest would be to add a notmuch_database_flush with a return value and then you can call that (and then call notmuch_database_destroy)? Alternatively maybe add notmuch_database_destroy_with_flush or something which does give a return value. notmuch_database_close is only called 3 times and notmuch_database_destroy lots of times so changing close is much less intrusive than changing destroy. But I don't know whether we would break any bindings or external programs etc. What do you think? Best wishes Mark