Bug 397315

## Observation

After upgrade from openSUSE Leap 42.3 to openSUSE Leap 15.0 I have a recurring problem that kmail does not refresh folders for at least one IMAP account after a certain time, e.g. no new messages are received, actions on existing items does not do not have an effect, e.g. a move is not synced to the server.

I called "kdebugsetting?" and enabled debug log output for all components already but so far that did not really provide me helpful details. What I tried as well is to delete all imap accounts and readd them. After that again all imap updates happen synchronous in two email clients (running thunderbird in parallel). Following https://de.manjaro.org/index.php?PHPSESSID=3m63tvu5ro6ud6tl7uuv1bleq0&topic=4795.0 I created an archive ~/local/tmp/akonadi_kontact_2018-07-20.tar.xz , deleted ~/.local/share/akonadi* as well as all config files with "mail" or "imap" in name from ~/.config/akonadi* as well as ~/.kde4/share/config/akonadi* and restarted akonadi and kmail, all messages got reindex when trying to access folders. I had to redo some settings, e.g. sent and archive folders. The versions of the packages are in most cases 17.12.3 as shipped with openSUSE Leap 15.0. Asked in IRC on freenode in  #opensuse-kde, it was suggested to try libkf5imap5 >= 18.04.3 and follow https://techbase.kde.org/KDE_PIM/Akonadi/Debug_IMAP . I did update that package from KDE:Applications:18.04 but the same problem seems to appear.
And it seems that IMAP is actually fine. seems something is trying to sync a folder and always at 4% for the same folder it gets stuck and then also INBOX is not updated anymore. Checking with akonadiconsole I can see that the agent in question is "akonadi_imap_resource_2" where the status is either "Syncing folder 2018 (4%)" or nothing at all in contrast to other agents including other imap resources that are in "Ready".

The action "Show Task List" reveals

```
ResourceScheduler: Online
 current task: 1227 SyncCollection collection 129 
 queue 0 is empty
 queue 1 1 tasks:
  1270 ChangeReplay 
 queue 2 is empty
 queue 3 1 tasks:
  1269 SyncCollectionAttributes collection 129 
 queue 4 4 tasks:
  1228 SyncCollection collection 130 
  1229 SyncCollection collection 131 
  1230 SyncCollectionTreeDone 
  1273 SyncCollectionTree 

IMAP tasks: 
```

And "Show Notification Logs shows:

```
Command: ItemChangeNotification 
 Session: MessageViewer-94699637932608 
 MetaData: QVector() 
 items: QVector(Item:271683(RID:208938, RREV:, mimetype: message/rfc822) 
 resource: akonadi_imap_resource_2 
 parentCollection: 113 
 parentDestCollection: -1 
 destinationResource:  
 itemParts: QSet() 
 addedFlags: QSet(\SEEN) 
 removedFlags: QSet() 
 addedTags: QSet() 
 removedTags: QSet() 
 addedRelations: QSet() 
 removedRelations: QSet() 
 operation: 7 
 
Command: ItemChangeNotification 
 Session: kontact-476707713 
 MetaData: QVector() 
 items: QVector(Item:271683(RID:208938, RREV:, mimetype: message/rfc822) 
 resource: akonadi_imap_resource_2 
 parentCollection: 113 
 parentDestCollection: -1 
 destinationResource:  
 itemParts: QSet(MDNStateAttribute) 
 addedFlags: QSet() 
 removedFlags: QSet() 
 addedTags: QSet() 
 removedTags: QSet() 
 addedRelations: QSet() 
 removedRelations: QSet() 
 operation: 2 
 
Command: ItemChangeNotification 
 Session: kontact-476707713 
 MetaData: QVector() 
 items: QVector(Item:271683(RID:208938, RREV:, mimetype: message/rfc822) 
 resource: akonadi_imap_resource_2 
 parentCollection: 113 
 parentDestCollection: 129 
 destinationResource: akonadi_imap_resource_2 
 itemParts: QSet() 
 addedFlags: QSet() 
 removedFlags: QSet() 
 addedTags: QSet() 
 removedTags: QSet() 
 addedRelations: QSet() 
 removedRelations: QSet() 
 operation: 3 
```

I can clean the task list by restarting or setting the agent to offline and online again but then the agent is again stuck in "Connection established." and folder contents still do not update. After some time it's "Ready", the INBOX folder still does not update.

After some time it is back to "Syncing folder '2018' (4%)" and the task list shows comparable content as written above. Maybe there is some "faulty entry" that akonadi trips over? If yes, how could I identify that entry?