From the following debug output that was captured after the problem appeared, we can see that the notifications indeed seem to pile up in the NotificationManager for some reason.

dev/noRealMessageCount disables all codepaths that rely on the message count. If that performs adequately, then we could just be using that.

This is apparently a synchronization issue.
We're currently waiting for more information (see otrs).

In imap/retrieveitemstask.cpp:

With the latest version it is now possible to introspect the notificationManager with:

appendAndCompress only optimizes collection modifications, so that's not it.

Akonadiconsole subscribes in notificationmodel.cpp directly to dbus, so it's unlikely that this is the reason.

Some additional checks that could be done:

Given that we do see some unrelated sync operations including non-SILENT modifications in the log, but still no notifications in akonadiconsole we can conclude that this is a problem where the akonadiserver fails to send any notifications to any process.

In T1321#22196, @mollekopf wrote:

The current hypothesis is:

• The DataStore does a reestablishConnectionIfLost because we lost the connection to the mysql server while a transaction was ongoing.
• m_transactionLevel is never reset to 0 so remains > 0
• commitTransaction get's m_transactionLevel > 1 and thus never emits transactionComitted
• NotificationCollector::dispatchNotification is always in transaction and thus always enqueues new notifications, and never emits them since it's waiting on transactionCommitted.

DataStore is a thread-local singleton that also instantiates NotificationCollector which would explain why this behavior is observed only for the session of kontact.
It doesn't explain why a restart of kontact isn't enough to fix the situation though it seems?

The current hypothesis is:

• The DataStore does a reestablishConnectionIfLost because we lost the connection to the mysql server while a transaction was ongoing.
• m_transactionLevel is never reset to 0 so remains > 0
• commitTransaction get's m_transactionLevel > 1 and thus never emits transactionComitted
• NotificationCollector::dispatchNotification is always in transaction and thus always enqueues new notifications, and never emits them since it's waiting on transactionCommitted.

From the latest information provided (otrs 07/20/2016 13:03:24):

• The UID STORE +FLAGS command is successfully executed and we can see the FETCH (REV 2) response)
• The Job Tracker also reports the ItemModifyJob as successful
• No notifications at all are visible in the notification monitor
• The "INSERT INTO PimItemFlagRelation ..." command is successfully executed as recorded by the querydebugger.

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