Entries with a null RemoteID are a perfectly valid case. It means that the item has been created in Akonadi and is waiting for the owning resource to store it in the remote storage (e.g. IMAP server, maildir, Google Contacts addressbook, .etc.).

The issue you are most likely referring to is that you have data stored in Akonadi that were not synchronized to the remote storage. This is indeed a known issue, we currently lack any mechanism that would be try to "upload" those entities again if the initial upload failed for any reason (this is not affected by network connectivity or shutting down computer before the item is uploaded). A solution is being worked on though.

I just observed another 5 occurrences of RemoteID = NULL. I did some forensic analysis. Hopefully the following observations help to pin down the problem.
1. Since I am running the akonadi database with my own MySQL server, I could use phpMyAdmin to do some queries, starting from "SELECT * FROM `pimitemtable` WHERE `remoteId` is NULL;"
I found that all these entries had a collectionID pointing to the trash can.
2. Apparently they were created by moving entries from an IMAP trash can to the main trash can. The IMAP server was davmail 4.7.1-2416-1, used as an interface to outlook.
3. There were three more entries put to the trash can by Kmail directly
    - these had a non-NULL RemoteID.
4. Emptying the trash can made the entries with RemoteID = NULL go away
    (no surprise, given what I said before).
5. I had a more emails in outlook that I could dispose. I repeated the following experiment two times.
a. Inside outlook (running in a Win7 VM), put these emails into trash (one or two at a time).
b. Wait for davmail to replicate the outlook trash into Kmail.
c. Run "SELECT * FROM `pimitemtable` WHERE `remoteId` is NULL;" and note the result.
d. Move the emails from IMAP trash to main trash.
e. Rerun "SELECT * FROM `pimitemtable` WHERE `remoteId` is NULL;" and note the difference.
=> One out of three emails disposed that way created a pimitemtable entry with RemoteID = NULL.
=> This trash can scenario may not be the only one creating this effect. But it is the least dangerous as these emails are to be disposed anyway - so no harm done !

Hope this helps !
Christoph Pospiech

In an earlier command it was written that "It means that the item has been created in Akonadi and is waiting for the owning resource to store it in the remote storage". I just observed something that potentially points to a different direction. I had a couple of NULL entries today, not related to the trash scenario as described in my previous comment. Apparently, these entries were pointing to an non-existent entry in ~/.local/share/akonadi/file_db_data. But they also had a foreign key pointing to a collection. For one of those collections there happened to be only one mail that I touched/moved into this collection. I checked in Kmail - and the mail was still there. Means - there is another entry in the PimItemtable for this mail, and the entry with remoteID = NULL appears to be really obsolete - a stale duplicate so to speak. My other (more general) observation is that these entries don't go away, even if the connection to the IMAP servers is re-established. I did similar checks for the other mails. - And then decided to eliminate the stale entries via "DELETE FROM `pimitemtable` WHERE `remoteId` IS NULL;" - knowing that there are delete cascades into the other tables. Would that be the general solution ?

Christoph Pospiech

I just managed to create some entries with RemoteID = NULL. I repeated the experiment - it appears to be reproducible. This is what I did -
1. In akonadi, SELECT * FROM `pimitemtable` WHERE `remoteId` IS NULL;
    Take note of the number of these entries.
2. In some IMAP inbox in Kmail , select some mails by mouse click (more than one).
3. Move them into some other folder by mouse left click and hold, moving them with the mouse
    and dropping them into the target folder.
4. In akonadi, re-check via SELECT * FROM `pimitemtable` WHERE `remoteId` IS NULL;
Observation: 
1. New NULL entries with collectionID pointing to the target folder, one less than the number of
    mails that were moved. 
2. All mails can be opened in the target folder.
3. The data seems to be there, execute
SELECT * FROM `parttable` WHERE pimItemID IN 
(SELECT id FROM pimitemtable WHERE remoteID IS NULL);
Check field `data` in parttable with a hex-editor.

Is there a way to recreate the mail as ordinary ASCII file in the target folder ?
Christoph

Perhaps I should stress the point that I believe that there is still an issue. Daniel Vrátil said it is perfectly normal to have NULL entries, when "the item has been created in Akonadi and is waiting for the owning resource to store it in the remote storage". It appears that the mails are all completely downloaded from IMAP (at least I don't miss any part), but akonadi appears to be confused about it....and it does not happen, if I move one mail at a time.

Christoph

Since the NULL entries by themselves are not considered to be a bug, I opened another bug report on mail moving (Bug 364243) and I will close this report.