Judging from the backtrace it could be that we have calls to exec that execute the eventloop:

Another potentially related crash:
https://support.kolabsys.com/provider?Action=AgentTicketZoom&TicketID=22211

Here's where I see the purpose in libmessageparser:

We could be chasing the wrong problem:
If the mail that this was tested with was internally already marked as read, then addFlags may have set flagsChanged to false, which would keep the changes empty, which would keep us out of the branch that sends the FETCH response, which makes the whole argument moot.

This is what we get in the debugger in the error state when trying to mark a mail as read:

kontact-1644948879 (0x7f0cb8012b60) 7421 UID STORE 86696 NOREV (+FLAGS (\SEEN)) 
kontact-1644948879 (0x7f0cb8012b60) 7421 OK DATETIME "23-Jun-2016 11:36:58 +0000" STORE completed

The example comes from the "OpenPGP encrypted one signed and one unsigned attachment"

Sandro, please add your thoughts and comments on the issue.

This is a wontfix

The information provided here suggests that the communication to the akonadi server remains functional (we can see the ASAP communication for the mark as read operation),
but for some reason the UI doesn't update.

Actually this seems to be a misinterpretation of the RFC https://tools.ietf.org/html/rfc5545#section-3.8.5.3

Issue confirmed, applies to invitation and local event.

Can't reproduce in most recent version.

Both should be fixed by now.

We sometimes missed sync intervals, and failed to synchronize collections that are only referenced, but not enabled.