User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:104.0) Gecko/20100101 Firefox/104.0

Steps to reproduce:

Made (lots of) filters to copy (to various folders selected by the filters) then delete a message from gmail Inbox accessed via IMAP.

This is an attempt to actually delete messages from gmail after downloading them, whereas gmail tries really hard to keep them in All Mail, unless explicitly deleted from Inbox... simply moving from inbox to a folder removes the Inbox tag but leaves the messages in All Mail.

Actual results:

Seemed to work in testing when one message came in at a time, but with multiple messages arriving, it seems to work for the first message, but additional messages create phantom messages in the destination folder(s), perhaps similar to those in bug 398498 from years ago. When opened, the phantom messages are blank. Early ones have subjects, in the message list, but later ones only have a date.

Happily the deleted copy (which winds up in gmail/Trash) is intact, and readable, but copying the messages back to Inbox en masse results in the same problem being repeated.

Copying them one at a time from Trash back to Inbox seems to work, as each message becomes the first message processed by the filters in turn.

Expected results:

All the messages should be copied and then deleted.

Because of the first message seeming to work, I wonder if copying messages is put in a queue if there is a copy of another message in progress, but the deletes happen when seen? This would result in the copy attempting to copy a deleted message, which might result in a phantom message? But I'm just speculating here, I have no knowledge of the internals of how filtering works.

I might be out to lunch on this one (I don't deal with IMAP, nor with GMAIL lately) but...
Is this bug related to Bug 1781792 ("When a filter copies multiple messages into local subfolders, the copied messages are empty!!") ?

There are some difficulties discussed there, and I left a few comments about dependence on the exact specific order of execution -- it seems that what we think should happen logically is not exactly what we explicitly & actually tell TB do do. (My apologies if not relevant here...)

It does seem like there could be a connection between these bugs, Dan, although my method of triggering the problem is different than reported in the other, so any testing should probably include both cases.

From reading the other bug, it does seem like there is a sequencing problem of some sort, but since there are multiple ways to trigger it, it does seem like a fix should be generated to make things happen in the proper sequence.