GNOME Bugzilla – Bug 776162
"Ignore Thread" does not always ignore thread
Last modified: 2018-06-14 09:05:01 UTC
Created attachment 342053 [details] screenshot 0. evolution-3.20.5-1.fc24.x86_64 1. right click on a mail thread in a subfolder of your IMAP inbox and click "Ignore Thread" (introduced in bug 300871) 2. See that new messages in that thread do not automatically get ignored.
Created attachment 342124 [details] Description of Ignore Thread
I guess that ignoring a thread just marks the incoming mails of that thread as read as specified in it's description. I have attached a screen shot that shows the description.
New messages that I received *after* setting "Ignore thread" did not get marked as read.
I guess that's not apparent in that screen shot,, so I got confused. I'll see if I could reproduce this.
(In reply to Kaartic from comment #4) > I guess that's not apparent in that screen shot,, so I got confused. To be more clear the attachment titled "screenshot"
(In reply to André Klapper from comment #3) > New messages that I received *after* setting "Ignore thread" did not get > marked as read. I tried reproducing the issue but failed in my attempt. The messages that arrived after setting "Ignore thread" did get marked as read.
And you tested with...? POP? IMAP? Something else? IMAP could have the fun that the Thread-ID is not locally cached...
I tested with IMAP. Is your related to POP ?
See comment 0.
Thanks for a bug report. Could you View->Show Deleted messages, then select that particular whole thread and send it to me (mention the bug report in the message subject, please), thus I could try with it, please? I noticed some misbehaviour with duplicate messages (same Message-ID header in the thread), but it's usually not the case in normal conversation (unless the list sends you two copies of the same message, when the user replies to all, instead to the list, though even then the messages should have different Message-ID-s). I do not know whether it's anything like that, I'd like to verify it first.
Those are internal emails so I cannot forward them... I don't see any duplication; I rather wonder if it has to do with using (GMail) IMAP and Evolution not being set to "download messages for offline usage" for that specific subfolder those emails are being filtered into.
Your new message (comment #0) shows as properly files in "the middle" of the thread, which is otherwise completely set to be ignored (shown in italic). That all is driven by user flags, which can, but are not necessarily, stored on the server. Gmail does support custom flags, as far as I know, thus it should not be this kind of issue. Thinking of it, the messages may not help me as such. Does it still misbehave for you? I would create a test build with some debug prints to try to figure out what's going on in the background (it would require a new message receive in that thread).
Created attachment 348028 [details] Screenshot Yes this still happens in a subfolder of my GMail inbox in 3.22.6. Messages end up in that subfolder by local filtering in Evolution (Specific Header "List-Id" contains "wmfall.lists.example.com" then "Move to Folder" then "Stop Processing"). Folder is not set to "Copy folder content locally for offline operation" in its "Properties" when right-clicking.
Same issue on 3.24.4-1.1.fc26. How can I help debugging this?
Maybe related to bug #785618, but that's a very wild guess, most likely misleading (there is not much difference between read/unread flags and custom flags for Camel, even you've this done in online, while the other bug is about offline). I tried to reproduce this again, by sending myself a message, which is received by Gmail and filled under a subfolder of Gmail's Inbox by an Evolution filter, similar to yours. It works. I noticed only once, that when I sent bunch of messages at once, like 4, the subfolder quickly flashed like having unread messages, but then it immediately made it back to no new messages there. (In reply to André Klapper from comment #14) > Same issue on 3.24.4-1.1.fc26. It is printing debug info on console. Search for the message subject, then what is followed after it, several lines.
Does this still misbehave for you, please? I mean, if you happen to noticed it. Ideally test with 3.28.0 or newer.
Still happens in latest 3.26. Need to wait a bit longer for 3.28...
Okay, thanks. I'm not sure whether there happened really any directly related change on the eds/Camel/IMAP+ side in 3.28, but if you are going to update one day anyway... :) There had been some changes around the flags and such for sure though.
Still happens in evolution-3.28.2-1.fc28.x86_64
Created attachment 372648 [details] Screenshot
Created attachment 372649 [details] 22:18 message in the screenshot in comment 10
Could you select that subpart of the thread, save it as mbox and send it to me, please? I'd like to see basically all messages in the screen shot. I'd like to verify their relation with the other messages, especially between the last which has the Ignore threads set and the first which has it missing. The corresponding folders.db file would also help, but it's quite complicated to extract it from there and I surely do not want the whole file from you (size and privacy concerns).
Created attachment 372650 [details] 22:41 message in the screenshot in comment 10 Note the 22:41 message in the screenshot has the mailing list in the CC field and not in the To field. Maybe a reason?
Ah, okay, these two should be sufficient. Could you add also UID column and note the UIDs of these two messages, please? With that it'll be easier to extract the information from the folders.db file.
With those UIDs known you can run: $ sqlite3 ~/.cache/evolution/mail/<accountuid>/folders.db \ "SELECT * FROM 'inbox/...' WHERE UID='123' OR UID='456'"
Created attachment 372651 [details] Screenshot, now with UIDs. (Supersedes comment 20)
(In reply to Milan Crha from comment #25) $:acko\> sqlite3 ~/.cache/evolution/mail/<accountuid>/folders.db "SELECT * FROM 'inbox/wmfall' WHERE UID='26802' OR UID='26801'" 26801|0|0|0|0|0|0|0|0|0|23153|1528749708|1528749724|Re: [Wmfall] Nxxxxxxx Xxxxx - Xxxxxxxxx x xxx xxxxxx|Kxxxx Zxxxxxx <kzxxxxxx@example12.com>|Cxxxxx Xxx <cxxx@example12.com>|Staff All <wmfall@lists.example12.com>|wmfall@lists.example12.com||||2733539986 280987214 5 162351630 2043127872 162351630 2043127872 1110414289 3323693154 189390198 105443742 967985625 1578435803||0||0 0 0|1528794572|1528794572 26802|16|0|1|0|0|0|0|0|0|18371|1528748339|1528748346|Re: [Wmfall] Nxxxxxxx Xxxxx - Xxxxxxxxx x xxx xxxxxx|Cxxxxx Xxx <cxxx@example12.com>|Staff All <wmfall@lists.example12.com>||wmfall@lists.example12.com||||162351630 2043127872 4 1110414289 3323693154 1110414289 3323693154 189390198 105443742 967985625 1578435803|ignore-thread|0||16 1 13-ignore-thread 0|1528789372|1528789372
This is a guess, but I think you received a pile of messages to that thread and they had been moved to the folder in an order which made the pairing with the existing thread impossible, like there had been no messages with expected Message-ID header available yet. As a proof, see the top message 26799 is marked as ignored and it arrived between the second to fifth unread message (26795..26798) and the last and the first unread message (26800 and 26801). With 'arrived' I mean when it had been copied into the subfolder by evolution filters. Could you give me result of this command, please? $ sqlite3 ~/.cache/evolution/mail/<accountuid>/folders.db \ "SELECT uid,part FROM 'inbox/wmfall' WHERE UID BETWEEN '26789' AND '26802'"
Makes sense. I apply a local filter in Evo to move the messages from the Gmail inbox to a subfolder. It's just not... expected behavior. :D $:acko\> sqlite3 ~/.cache/evolution/mail/<accountuid>/folders.db "SELECT uid,part FROM 'inbox/wmfall' WHERE UID BETWEEN '26789' AND '26802'" 26789|189390198 105443742 2 967985625 1578435803 967985625 1578435803 26790|1110414289 3323693154 3 189390198 105443742 189390198 105443742 967985625 1578435803 26791|2117830153 3770652086 0 26792|741756057 1305629260 2 967985625 1578435803 967985625 1578435803 26793|1607697552 2950538860 3 741756057 1305629260 741756057 1305629260 967985625 1578435803 26794|2661174348 3807100026 0 26795|2279649260 3363885845 6 2733539986 280987214 2733539986 280987214 162351630 2043127872 1110414289 3323693154 189390198 105443742 967985625 1578435803 26796|4129731732 3201363761 7 2279649260 3363885845 2279649260 3363885845 2733539986 280987214 162351630 2043127872 1110414289 3323693154 189390198 105443742 967985625 1578435803 26797|860531063 2327104930 8 4129731732 3201363761 4129731732 3201363761 2279649260 3363885845 2733539986 280987214 162351630 2043127872 1110414289 3323693154 189390198 105443742 967985625 1578435803 26798|4255008047 889262079 9 860531063 2327104930 860531063 2327104930 4129731732 3201363761 2279649260 3363885845 2733539986 280987214 162351630 2043127872 1110414289 3323693154 189390198 105443742 967985625 1578435803 26799|1577917107 2581432611 2 967985625 1578435803 967985625 1578435803 26800|257261377 3490698215 5 162351630 2043127872 162351630 2043127872 1110414289 3323693154 189390198 105443742 967985625 1578435803 26801|2733539986 280987214 5 162351630 2043127872 162351630 2043127872 1110414289 3323693154 189390198 105443742 967985625 1578435803 26802|162351630 2043127872 4 1110414289 3323693154 1110414289 3323693154 189390198 105443742 967985625 1578435803
Here [1] is a test build with a test patch which tries to not rely on the In-Reply-To message state when it is currently discovered message too, unless it's already marked to ignore-thread. In case you'd hit the bug, there's printed a message like the one below to indicate it: > folder_cache_check_ignore_thread: would use UID 13200 as In-Reply-To for UID > 13201 in 'inbox/something', which is a new message (has ignore-thread:0) ### I suppose you'll see it the best in the morning, when the messages will pile up to be filtered to respective subfolders. You can mark the unread messages from the screen shot to ignore thread, unless you did that already. It'll give better results in the tests. Thanks for testing. [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=27576812
(In reply to Milan Crha from comment #30) > Here [1] is a test build with a test patch which tries to not rely on the > In-Reply-To message state when it is currently discovered message too, > unless it's already marked to ignore-thread. I'll extend the patch a bit, because it can still misbehave when a long subthread is received at once, "in a wrong order" of the messages. It may not change much for you, because you ignore whole thread, while the added change will be usable when some parts of the thread being ignored and some not. The idea behind the change is to process messages in order of the thread, not in order the messages had been received. I'll probably commit it straight to the sources. I'm not sure yet.
evolution-3.28.2-1.2.fc28.x86_64 says: folder_cache_check_ignore_thread: would use UID 1089474 as In-Reply-To for UID 1089475 in 'INBOX/maniphest', which is a new message (has ignore-thread:0) ### folder_cache_check_ignore_thread: would use UID 26847 as In-Reply-To for UID 26840 in 'INBOX/wmfall', which is a new message (has ignore-thread:0) ### folder_cache_check_ignore_thread: using UID 26842 as In-Reply-To for UID 26843 in 'INBOX/wmfall', which is a new message (has ignore-thread:1) ### folder_cache_check_ignore_thread: would use UID 26844 as In-Reply-To for UID 26845 in 'INBOX/wmfall', which is a new message (has ignore-thread:0) ### folder_cache_check_ignore_thread: using UID 26843 as In-Reply-To for UID 26846 in 'INBOX/wmfall', which is a new message (has ignore-thread:1) ### folder_cache_check_ignore_thread: would use UID 26845 as In-Reply-To for UID 26847 in 'INBOX/wmfall', which is a new message (has ignore-thread:0) ### folder_cache_check_ignore_thread: would use UID 1089381 as In-Reply-To for UID 1089382 in 'INBOX/maniphest', which is a new message (has ignore-thread:0) ### folder_cache_check_ignore_thread: would use UID 1089398 as In-Reply-To for UID 1089399 in 'INBOX/maniphest', which is a new message (has ignore-thread:0) ### folder_cache_check_ignore_thread: would use UID 1089398 as In-Reply-To for UID 1089401 in 'INBOX/maniphest', which is a new message (has ignore-thread:0) ### folder_cache_check_ignore_thread: using UID 26848 as In-Reply-To for UID 26853 in 'INBOX/wmfall', which is a new message (has ignore-thread:1) ### folder_cache_check_ignore_thread: would use UID 1089351 as In-Reply-To for UID 1089352 in 'INBOX/maniphest', which is a new message (has ignore-thread:0) ### I don't know how this is helpful for you.
It shows that you'd hit the bug couple times. Especially the UIDs at lines with "(has ignore-thread:1)" would not be marked as ignored without the patch.
Ah! I naively thought the test build only adds debug spew and after that output in comment 32 I was confused that all messages were correctly 'ignored'. Yay! Thanks!
I thank your for your help with this. The extended patch works here, thus I committed it straight to the sources. Created commit 5f6de5af8b in evo master (3.29.3+) Created commit 80a0bfdee3 in evo gnome-3-28 (3.28.3+)