Item "255451" in collection "108" has no RID.

[Erik Quaeghebeur]

>> One can use akonadiconsole to get rid of them.  Start akonadiconsole
>> 
>>   * Read the warning that pops up carefully.
>>   * tab 'DB Browser': select collectiontable, press [refresh]
>>     -> check with name collection id 108 has
>>   * tab 'Browser' select the collection with the name you found in
>>     the step above. Sort list of the right hand side by 'Remote ID'
>>     (list all item with no RID grouped together) or scroll to the ID 255451
>>   * Inspecting the payload shows you the content and may give
>> you a hint how to reproduce the problem for a bug report
>>   * Right click on the item -> delete

This approach also works if you have ‘dirty’ items even with a RID. For 
this, use the DB Browser on the PimItemTable and sort by dirty (value 1 
indicates an issue)

> Thing is, "fixing" it this way can cause data loss. Why?
>
> […] So the item, for example the mail, 
> *may* be *just* in the database and *nowhere* else. In that case, if you 
> delete it from the database, the item it lost.

If it is in the database, you should be able to see it in, e.g., kmail. 
There, move or copy it to another folder to create an item that will get a 
RID. Then delete the RIDless one.

> So, before deleting it, did you make sure you have the item *in* the 
> resource, i.e. on the IMAP server for example or in the maildir?

AFAIK, an item without an RID is not linked to an item in the resource. 
They create a wrong impression in your tools (such as kmail) that certain 
items are in the resource. That is dangerous and a good reason to make sure 
that there are not RIDless items in your database.

> Due to this I have chosen to ignore those messages for now, hoping that 
> one day Akonadi will gain the ability to retry replaying the changes to 
> the resources.

I think this is dangerous: say that the akonadi database is corrupted and 
you need to recreate it from the resources? Then all the RIDless items 
without an actual counterpart in the resource will be gone.

Concerning replaying: the information for that is in 
~/.config/akonadi/*_changes.dat files. When you delete dirty items, delete 
the non-empty files of these here, as they are not valid anymore. Do this 
while akonadi has been stopped (which you can do in akonadiconsole).

(BTW, The fact that akonadi stores such files in a configuration directory 
is inappropriate, I think. It should be beneath ~/.cache or ~/.local/var.)

> […] I believe there is a bug report open 
> at it - well at least one – but I do not recall specifics at the moment.

https://bugs.kde.org/show_bug.cgi?id=360834
https://bugs.kde.org/show_bug.cgi?id=406856


Erik