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

[test]

On Friday, May 8, 2020 10:31:05 AM CEST Martin Steigerwald wrote:
> Dear Achim, dear René, dear community,
> 
> Achim Bohnet - 08.05.20, 10:05:32 CEST:
> > On Thursday, 7 May 2020 20:58:16 CEST René J.V. Bertin wrote:
> > > On Thursday May 07 2020 20:01:21 test wrote:
> > > >'akonadictl fsck' gives lots of messages like in the subject.  Are
> > > >those bugs, and if so, how can I fix them?
> > > 
> > > I can't comment on what they are, but I don't think you can fix them
> > > if the command that's supposed to fix issues cannot. What you can
> > > try is a "vacuum", which should clean out your database, after
> > > which messages are reloaded from the remote server (when you launch
> > > KMail). With a bit of luck that will get rid of the offending
> > > whatever-they-are.
> > 
> > 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
> > 
> > Now at least akonadictl fsck is happy.
> > This always worked for me.
> 
> Interesting idea, never considered to delete them this way.
> 
> Thing is, "fixing" it this way can cause data loss. Why?
> 
> "Item without RID" as discussed here quite some time ago are items that
> Akonadi was not able to store into the resource. For example with IMAP a
> mail it got, but was not able to store onto the IMAP server. For example
> with maildir, a mail it got, but was not able to store onto the
> filesystem.
> 
> I do not understand how this can ever happen with maildir, however it
> *does* happen.
> 
> Now Akonadi *does not* try again. 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.

How do I know if the message is still in the database?

> 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?

How do I know if the message is still on the IMAP server?  Even if kmail were 
to show me message numbers, I wouldn't know if kmail shows the numbers the 
IMAP server uses or others.

> 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.
> 
> And yes, this is a FAQ, and this is known for a long, long time. I hope
> someday a developer will fix this. I believe there is a bug report open
> at it - well at least one – but I do not recall specifics at the moment.

I'm getting the feeling that whatever database kmail is using is somewhat 
broken.  Can't I just use mariadb instead, which is running on a server on the 
network anyway?