Folder deletion problem (Re: Problem with imap resource)

[David Faure]

On vendredi 13 janvier 2017 09:18:41 CET David Faure wrote:
> Any idea why only followupreminder_agent is getting a proper ancestor chain?

Answer: because it's the only one that had the parent in the collectionCache (for some reason).

MonitorPrivate::emitNotification and MonitorPrivate::emitCollectionNotification are the problem here.

When it works, it's because
        const Collection parent = collectionCache->retrieve(colNtf.parentCollection());
found the parent in the cache.

Compare
akonadi_newmailnotifier_agent(9273)/default Akonadi::MonitorPrivate::emitNotification: collectionCache for 948 said 948 remoteid= "inbox" name= "inbox"
with
akonadi_maildir_resource_0(9267)/default Akonadi::MonitorPrivate::emitNotification: collectionCache for 948 said -50 remoteid= "" name= ""

After that, emitCollectionNotification simply does:
    parent = Collection(msg.parentCollection());
which sets it to id=948 remoteId="", and further down
   collection.setParentCollection(parent);
which stores that into the collection that is then passed to collectionRemoved().

This all seems quite fragile, it all depends on what's in collectionCache.

And MonitorPrivate::ensureDataAvailable says it can't fill that cache in case of collection removals.

    if (msg.type() == Protocol::Command::CollectionChangeNotification
            && static_cast<const Protocol::CollectionChangeNotification &>(msg).operation() == Protocol::CollectionChangeNotification::Remove) {
        //For collection removals the collection is gone anyways, so we can't fetch it. Rid will be set later on instead.
        return true;
    }

How is this supposed to work then?

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5