>So fetching from sent folder for copying and applying the tag/label happen in random order? Do you see any issues with the "Re: " prefix as well? "Re:" is the same issue since missing Re would be caused by imap FETCH of message triggered by the filter occurring before the \Answered flag is set on the new message in Sent folder. > The puzzling thing is that the additional call to UpdateFolderWithListener() introduced in bug 1990129 is causing all the damage, so how does that relate to the course of the events? It causes an "update" on the Sent folder resulting in an imap SELECT of Sent folder and then fetch of all its imap FLAGS. This probably varies the timing or order of when the UID STORE and message FETCH occur. >I noticed that this code is causing the "damage": https://searchfox.org/comm-central/rev/60a66232310979b430b99cd8044ca61dd0b284a7/mailnews/imap/src/nsImapMailFolder.cpp#685-699 >Clearing the flag avoids the problem. Is this a valid approach? Not sure what this does but, by itself, it doesn't fix the problem when I tried it. My first filter run failed to transfer the tag to LFs.
Bug 2008314 Comment 12 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
>So fetching from sent folder for copying and applying the tag/label happen in random order? Do you see any issues with the "Re: " prefix as well? ~~"Re:" is the same issue since missing Re would be caused by imap FETCH of message triggered by the filter occurring before the \Answered flag is set on the new message in Sent folder.~~ Edit: This is wrong. The Re: on the subject is in the file put into Sent folder by imap append. Why it is cleared in the move destination folder (apparently by the update of appended Sent folder that I added post 140) is TBD. See comment 21. > The puzzling thing is that the additional call to UpdateFolderWithListener() introduced in bug 1990129 is causing all the damage, so how does that relate to the course of the events? It causes an "update" on the Sent folder resulting in an imap SELECT of Sent folder and then fetch of all its imap FLAGS. This probably varies the timing or order of when the UID STORE and message FETCH occur. >I noticed that this code is causing the "damage": https://searchfox.org/comm-central/rev/60a66232310979b430b99cd8044ca61dd0b284a7/mailnews/imap/src/nsImapMailFolder.cpp#685-699 >Clearing the flag avoids the problem. Is this a valid approach? Not sure what this does but, by itself, it doesn't fix the problem when I tried it. My first filter run failed to transfer the tag to LFs.