Missing bodies

[Daniel Vrátil]

On Monday, 20 August 2018 22:40:27 CEST David Faure wrote:
> No, this isn't about a murder-related TV series ;)
> 
> I just had a bug in akonadi where some old emails are not readable when
> being offline, despite the "Download messages for offline use" option being
> checked in the IMAP settings.

Any chance you turned this option on later on when some emails have already 
been downloaded with the "offline mode" off?

> 
> Investigation showed this in the logs:
>   ItemRetrievalJob::start: processing retrieval request for item (1447066) 
> parts: ("HEAD", "RFC822")  of resource: "akonadi_imap_resource_2"
> ItemRetrievalManager::retrievalJobFinished: ItemRetrievalJob finished for
> request 0x7f13a41b0550 , error: "Unable to retrieve item from resource:
> Cannot fetch item in offline mode."

Well, you are offline so Akonadi can't fetch the body. The important part is 
that the attempt for retrieval happened, so the system works.

> 
> which leads to this SQL query:
> 
> MariaDB [akonadi]> select pimItemId,partTypeId,datasize,version,storage from
> parttable where pimItemId=1447066;
> +-----------+------------+----------+---------+---------+
> 
> | pimItemId | partTypeId | datasize | version | storage |
> 
> +-----------+------------+----------+---------+---------+
> 
> |   1447066 |          5 |        0 |       1 |       0 |  (RFC822) --- why
> |   0??
> |   1447066 |          7 |        0 |       1 |       0 |  HEAD
> |   1447066 |          8 |      765 |       2 |       0 |  ENVELOPE
> |   1447066 |         11 |        1 |       0 |       0 |  MDNStateAttribute
> 
> +-----------+------------+----------+---------+---------+
> 4 rows in set (0.00 sec)
> 
> Comments in last column are mine, obviously. Empty RFC822, that shouldn't
> happen, should it?

It is a perfectly valid state. It means that the payload part has been expired 
from Akonadi and will be re-fetched the next time you try to display the 
email.

> MariaDB [akonadi]> select pimItemId,partTypeId,datasize,version,storage from
> parttable where partTypeId=5 AND datasize=0; shows 3124 rows!!
> 
> What is it that might lead to bodies (RFC822) not being stored in the DB?
> 
> Could this happen when failing to save to
> ~/.local/share/akonadi/file_db_data/* ? I had a few "partition full"
> scenarios lately. Although, hmm, that was the root filesystem, not the home
> one.

Full partition would likely fail cause the system to fail more "safely", like 
database failing to commit a transaction.

> 
> In any case, apart from the root case, I wonder if we could
> 1) propagate the error to the user when saving fails, and

Although this wasn't a failure, our error reporting in general indeed is 
insufficient


> 2) download all missing bodies next time we're online to ensure that those
> emails will indeed be readable from an air plane...

This could be done by extending the CollectionScheduler,  but depends on what 
the cost of those queries is to make it viable...

-- 
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: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20180821/8486ee64/attachment.sig>