EntityTreeModelPrivate::monitoredItemChanged

[Daniel Vrátil]

On Saturday, April 22, 2017 2:02:11 PM CEST Martin Koller wrote:
> On Samstag, 22. April 2017 13:00:21 CEST Daniel Vrátil wrote:
> > On Saturday, April 22, 2017 9:27:48 AM CEST Martin Koller wrote:
> > > In EntityTreeModelPrivate::monitoredItemChanged it issues a warning when
> > > a
> > > received item is not known in the internal QHash.
> > > However I think it does not make sense to issue this warning, since a
> > > mail
> > > fetching resource (like my test or a POP resource, etc.)
> > > will not have the items it receives from the server in the hash ever. Am
> > > I
> > > right ?
> > 
> > The way the "flow" is, is:
> > 
> > 1) POP3 Resource runs ItemCreateJob
> > 2) Akonadi server creates the PimItem, sends ItemCreated notification to
> > all 3) All email agents, applications and their ETMs that watch emails
> > get the new Item
> > 4) Some agent or client changes the Item through ItemModifyJob
> > 5) Akoandi server processes the changes, sends ItemModified notification
> > to all 6) All email agents, applications and their ETMs that watch emails
> > get the notification
> > 
> > Expected: ETMs process the change
> > Reality: ETMs complain about the "stale notification"
> > 
> > This leads me to believe that the real problem is either in step 2 or step
> > 3.
> I found out now that (in case of the akonadi_mailfilter_agent) the ETM
> receives the item, but in monitoredItemAdded() it is not inserted into the
> QHash since the function returns at
> 
>     //Adding items to not yet populated collections would block fetchMore,
> resulting in only new items showing up in the collection //This is only a
> problem with lazy population, otherwise fetchMore is not used at all if
> ((m_itemPopulation == EntityTreeModel::LazyPopulation) &&
> !m_populatedCols.contains(collection.id())) { return;
>     }
> 
> hmmm ... does this ring a bell ?

Nice find! And monitoredItemChanged() does not take the lazy population in 
account, thus printing the warning. So the fix would be to simply add the same 
lazy population check to monitoredItemChanged() and simply ignore the change 
in that case.

Dan

-- 
Daniel Vrátil
www.dvratil.cz | dvratil at kde.org
IRC: dvratil on Freenode (#kde, #kontact, #akonadi, #fedora-kde)

GPG Key: 0x4D69557AECB13683
Fingerprint: 0ABD FA55 A4E6 BEA9 9A83 EA97 4D69 557A ECB1 3683
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20170422/c881017d/attachment.sig>