[Akonadi] [Bug 436188] New: CalDav entry not synced: Fails silently (remoteID NULL in pimitemtable)

bugzilla_noreply at kde.org bugzilla_noreply at kde.org
Sun Apr 25 22:33:42 BST 2021


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

            Bug ID: 436188
           Summary: CalDav entry not synced: Fails silently (remoteID NULL
                    in pimitemtable)
           Product: Akonadi
           Version: 5.16.3
          Platform: Ubuntu Packages
                OS: Linux
            Status: REPORTED
          Severity: normal
          Priority: NOR
         Component: DAV Resource
          Assignee: kdepim-bugs at kde.org
          Reporter: bugs-kde at quitesimple.org
  Target Milestone: ---

SUMMARY


I was in the process of creating several calendar entries, however one entry
was not synced with the remote CalDav Server:

SELECT * FROM pimitemtable WHERE remoteID IS NULL;
ERROR 2006 (HY000): MySQL server has gone away
No connection. Trying to reconnect...
Connection id:    22
Current database: akonadi

+------+-----+----------+----------------+------+--------------+------------+---------------------+---------------------+-------+------+
| id   | rev | remoteId | remoteRevision | gid  | collectionId | mimeTypeId |
datetime            | atime               | dirty | size |
+------+-----+----------+----------------+------+--------------+------------+---------------------+---------------------+-------+------+
| 1066 |   1 | NULL     | NULL           | NULL |           51 |          1 |
2021-04-25 20:42:33 | 2021-04-25 21:06:23 |     1 | 1464 |
+------+-----+----------+----------------+------+--------------+------------+---------------------+---------------------+-------+------+
1 row in set (0.003 sec)

It's possible that the Wifi connection during the process was unstable,
however, I don't consider this that important, as:

1) I did not receive an indication by KOrganizer that this item was not synced.
It's thus a silent fail. The item is only locally visible  resulting in a
suboptimal situation. Users affected probably think that the items have been
stored on the server and would therefore be available for other devices.

2) Akonadi should retry storing that item on the server. Right now remoteID is
NULL, and that seems to be it. 

So, I think for the best user experience:
 - Some kind of error message when something like this happens should appear.
 - That akonadi tries to resolve the situation by itself. 

In the meantime, what can a user do to resolve this? Can I tell akonadi to try
sending entries with remoteID NULL again?

akonadictl fsck:

Looking for resources in the DB not matching a configured resource...
Looking for collections not belonging to a valid resource...
Checking collection tree consistency...
Looking for items not belonging to a valid collection...
Looking for item parts not belonging to a valid item...
Looking for item flags not belonging to a valid item...
Looking for overlapping external parts...
Verifying external parts...
Found 3 external files.
Found 3 external parts.
Found no unreferenced external files.
Checking size treshold changes...
Found 0 parts to be moved to external files
Found 0 parts to be moved to database
Looking for dirty objects...
Collection "Search" (id: 1) has no RID.
Collection "OpenInvitations" (id: 15) has no RID.
Collection "DeclinedInvitations" (id: 16) has no RID.
Collection "CENSORED" (id: 29) has no RID.
Found 4 collections without RID.
Item "1066" in collection "51" has no RID.
Found 1 items without RID.
Found 0 dirty items.
Looking for rid-duplicates not matching the content mime-type of the parent
collection
Checking Birthdays & Anniversaries
Checking Local Folders
Checking Notes
Checking Personal Contacts
Checking Search
Checking akonadi_davgroupware_resource_2
Checking akonadi_davgroupware_resource_4
Checking akonadi_davgroupware_resource_5
Checking DeclinedInvitations
Checking OpenInvitations
Checking drafts
Checking inbox
Checking outbox
Checking sent-mail
Checking templates
Checking trash
Checking [censored]
Checking [censored]
Checking [censored]
Checking [censored]
Checking [censored]
Checking [censored]
Checking [censored]
Checking [censored]
Checking [censored]
Checking [censored]
Checking [censored]
Checking [censored]
Checking [censored]
Migrating parts to new cache hierarchy...
Checking search index consistency...
Akonadi Indexing Agent is not running, skipping test
Flushing collection statistics memory cache...
Making sure virtual search resource and collections exist
Consistency check done

I did have that same issue with a different CalDav server a few months ago,
hence I created a script to monitor for this situation should it appear again,
which it now unfortunately did.

-- 
You are receiving this mail because:
You are the assignee for the bug.


More information about the Kdepim-bugs mailing list