Race condition when deleting multiple attachments

[Volker Krause]

On Mittwoch, 28. April 2021 21:23:43 CEST Ingo Klöcker wrote:
> Hi,
> 
> when deleting a second attachment quickly after the first one, Akonadi runs
> into a problem:
> org.kde.pim.akonadiserver: Invalid attempt to modify the remoteID for item
> 1071444 from "272" to "271"
> org.kde.pim.akonadiserver: Error while handling command ModifyItems on
> connection MessageViewer-43686032 (0x7fe56c4fe110)
> 
> I guess the problem is that the modification of the payload after the
> deletion of the first attachment did not yet make the roundtrip KMail ->
> Akonadi -> IMAP server -> Akonadi -> KMail and therefore KMail/Akonadi uses
> the old remoteID for the modification of the payload after the deletion of
> the second attachment.
> 
> Any ideas, how to avoid this problem? Would it be sufficient to wait for the
> first Akonadi::ItemModifyJob to finish? Or do I need to wait until the
> remoteID is updated? What about offline mode?

That looks like a problem with IMAP emulating content changes by creating new 
items and deleting the old one (as IMAP can't modify content of existing 
messages). Strictly sequential execution of the client-side modification jobs 
should already be the case, so waiting for the result wont help. Waiting for a 
remote id modification is also not a good idea, as that is something specific 
to IMAP's limitations, it wont happen for any other backend.

However, the exact order would probably not even matter if the client wouldn't 
attempt to modify the remote id (that's something only the owning resource is 
allowed to do). The easiest way to do that is to not even retrieve remote ids 
in the first place, by disabling that in ItemFetchScope. If that's not an 
option, setting the remote id to a null string seems to also skip the 
modification from looking at ItemModifyJob.

But my memories of all this have become blurry, if Dan says something else 
he's probably right :)

Regards,
Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20210429/ce0f8352/attachment.sig>