542596 - Provide methods for move filters to not clobber previous async actions

Status: NEW

(MailNews Core :: Filters, defect)

Description

[Kent James (:rkent)]

I added the following comment to a user on mozillazine, who complained that a Save Attachments followed by a Move action failed to save the attachment. But the issue is broader than FiltaQuilla:

===
There are a variety of issues that come up in filters when people try to combine any action that is applied async with a move. The issue is that the move results in a delete of the message in the original folder, while actions on the message rely on the message still existing. The filter actions are automatically reordered so that the move happens last, but this does not help if a message action is performed async. This results in a race condition, so that errors of this sort can sometimes be random.

None of this depends directly on FiltaQuilla. However, FiltaQuilla introduces a few new actions that are async (including not only SaveAttachments but also Train as Junk, or potentially things like Launch). But there are existing standard filter actions that could also be issues here.

So I would not call this a bug in FiltaQuilla exactly, but an underlying issue that is made more apparent by some of the more complex actions that FiltaQuilla allows. That is enough to reject a core patch by the way, but I think the standard should be a little lower in an extension. Should we disallow this action because in some cases it can fail? I think not in an extension, but I do need some warning notes perhaps.

At the FiltaQuilla level, I don't know of any way to solve this, short of adding single custom actions like "Save attachments then Move" (like I do with "Copy As Read") that combine a couple of problematic steps together. In that sort of case, I can control the whole process and make it work. But not with the standard Move which provides no hook to solve this.
===

Comment 1

[Wayne Mery (:wsmwk)]

bug 1071628 is a dupe?