Possible some threads are not complete due to bug?

[David Bremner]

Xu Wang <xuwang762 at gmail.com> writes:

>
> $ notmuch search --output=threads "id:MYMSGID"
> thread:000000000000a125
> $ notmuch search --output=messages "thread:000000000000a125"
> id:MYMSGID
> $
> # I know that MYMSGIDREPLY did respond to that message. I have it in
> my mutt mailbox and it shows the down-right arrow signifying this. I
> inspect the headers and there is indeed a header in MYMSGIDREPLY that
> says "In-Reply-To: <MYMSGID>". I then do...
> $ notmuch search --output=threads "id:MYMSGIDREPLY"
> thread:000000000000c125
> $ notmuch search --output=messages "thread:000000000000c125"
> id:MYMSGIDREPLY
> $

If the thread-id's are accurate, then it looks like the two messages are
not in the same thread according to notmuch (it's easy to be fooled
because the thread-ids are so similar).  I can't really explain how
those messages might have ended up in different threads. 

  - One potential issue is that if message ids are extra long or badly
  formed, then notmuch might make up a new message id. In that case your
  thread-id search wouldn't work at all.

  - If there are actually multiple (unrelated) files with message-id
    MYMSGIDREPLY, then the indexed one might not have the in-reply-to
    header. But in this case you could tell by

    notmuch show id:MYMSGIDREPLY

    and/or

    notmuch search --output=files id:MSGIDREPLY

In order for the thread-ids to change when you run "notmuch new", I
_think_ that there has to be a third message in the thread disovered.

So it's a mystery. If it happens again with public messages, it would be
worth sharing the messages (as attachements) with the list, just in case
there is something in the headers that explains it.