Re: [PATCH] test: add known broken test for duplicate thread-id terms

Subject: Re: [PATCH] test: add known broken test for duplicate thread-id terms

Date: Mon, 17 May 2021 07:02:00 -0300

To: Michael J Gruber, notmuch@notmuchmail.org

Cc:

From: David Bremner


Michael J Gruber <git@grubix.eu> writes:

> David Bremner venit, vidit, dixit 2021-05-15 15:05:07:
>> According to my bijection, this bug has been present since commit
>> 411675a6ce in 2017. It is apparently harmless for regular use, but
>> does make notmuch crash when compiled with -DDEBUG_DATABASE_SANITY.
>
> If a message "belongs" to 2 threads, doesn't it mean that it "belongs"
> to at least 1 that it doesn't really belong to?

Sure, conceptually a message should belong to only one thread. But it
isn't clear what having an extra thread-id attached to a message really
means. As far as I can tell, _notmuch_message_get_term will just always
choose the lexicographically first (i.e. minimum) term.

> The recent problem with "db update in pre-new hook" surfaced as extra
> thread assignments for the wrong messages (making them show up the wrong
> thread, too).

To the best of my knowledge, this was caused by something else, namely
the in-memory view of last thread-id being out of sync with the database.

> I meanwhile noticed that they are more common, but am wondering whether
> they are really harmless?

It's possible that I missed some harmful effect. Anton reminded me on
IRC of some previous issues with threading that could conceivably be
related. I guess it would be more precise to say "Duplicate thread-id
terms have not been demonstrated to cause problems in regular use". I
mean, they're obviously a bug.
_______________________________________________
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-leave@notmuchmail.org

Thread: