astroidmail
Fix segfault on opening multiple threads for one entry in thread list
This is my take on #695
I'm not a C++ dev though (mainly I'm a Rust dev), thus I guess this is something one might not want to have here.
For my case, it fixes the crash when opening a thread where notmuch returns multiple threads for one thread id. Please have a look.
Note that this does not open multiple new panes, one for each thread returned by notmuch. I would have expected that behaviour, but it does not do that. I don't know why.
on_thread is used several places, not sure if it is safe to apply the function to all threads. E.g. a user-defined hook to delete a thread. Why does notmuch return several threads? Is it a notmuch bug? Maybe it is safer to work on the first thread if we cannot avoid the underlying issue?
TBH I don't know. But I've experienced this before in notmuch. As far as I can see, nothing (in the notmuch docs) says that for a thread:<thread id> query, notmuch does only return one thread.
So I guess it is actually expected to return multiple thread and the bug is on our side here when we expect only one thread to be returned.
Thread IDs should be unique. I think I've discussed this on the list before. Maybe check with notmuch list or with #notmuch?
ons. 22. jul. 2020, 15:37 skrev Matthias Beyer [email protected]:
TBH I don't know. But I've experienced this before in notmuch. As far as I can see, nothing (in the notmuch docs) says that for a thread:
query, notmuch does only return one thread. So I guess it is actually expected to return multiple thread and the bug is on our side here when we expect only one thread to be returned.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/astroidmail/astroid/pull/696#issuecomment-662457853, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAN363J2CZR6DW6PYPBNRTR43TRJANCNFSM4PEWLWZQ .
I found this: https://notmuchmail.org/pipermail/notmuch/2018/026381.html
I think that thread was promoted by an astroid issue. Maybe we should pick up the issue again with notmuch? Does the threads always contain the same messages?
ons. 22. jul. 2020, 15:40 skrev Matthias Beyer [email protected]:
I found this: https://notmuchmail.org/pipermail/notmuch/2018/026381.html
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/astroidmail/astroid/pull/696#issuecomment-662459327, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAN363CA7IQ3WNTQPY26N3R43T3XANCNFSM4PEWLWZQ .
Does the threads always contain the same messages?
Not sure what you mean by that.
From what I see in the codebase right now, Db::on_thread is not used too extensively. Maybe it would be worth a try to check all cases and rewrite it to not expect there be only one thread anymore?
Hm, I think it is an error from the notmuch lib. We should bail or try to recover. Executing the same action, intended to be done on a single unique thread, multiple times is not expected by the rest of astroid or the user and could easily cause further bugs down the line.
ons. 22. jul. 2020, 15:46 skrev Matthias Beyer [email protected]:
Does the threads always contain the same messages?
Not sure what you mean by that.
From what I see in the codebase right now, Db::on_thread is not used too extensively. Maybe it would be worth a try to check all cases and rewrite it to not expect there be only one thread anymore?
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/astroidmail/astroid/pull/696#issuecomment-662462402, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAN36YRLARANVM36LYSZS3R43USLANCNFSM4PEWLWZQ .
I have solved this problem by running notmuch reindex on the first of such split threads. This corrects it to one thread. Is there a reason this could not be attempted by astroid as a convenience to the user? Or does reindexing potentially cause problems?
I have solved this problem by running
notmuch reindexon the first of such split threads. This corrects it to one thread. Is there a reason this could not be attempted by astroid as a convenience to the user? Or does reindexing potentially cause problems?
Thanks it has solved a similar problem here.
