Ask / Submit

Jolla resurrects old reminders

asked 2017-10-12 23:02:25 +0300

birefringence gravatar image

updated 2017-10-13 20:49:16 +0300

I recently observe the phenomenon that old reminders reappear on other devices synced to the same CalDAV calendar. I have SailfishOS on Jolla 1 synchronized via a DAViCal v1.1.5 server.

Everytime the phone synchronizes, old reminders are re-displayed in Thunderbird. It does not seem to affect all events, but the problem gets worse continuously until I completely reset the calendar on the Jolla.

The same problem is mentioned here, but I wanted to have a separate post to make the problem more visible.

This is a regression, it used to not happen until some time ago (probably the SFOS 2.1 update, but I'm not certain about this).


What happens is that the


tag is removed from the event even if it wasn't touched at all on the Jolla.

edit retag flag offensive close delete


@birefringence Thanks a lot for identifying the technical background of the problem!

Maus ( 2017-10-13 21:37:01 +0300 )edit

The testing packages mentioned in this thread don't fix the undead reminders.

Maus ( 2017-10-15 21:21:18 +0300 )edit

1 Answer

Sort by » oldest newest most voted

answered 2017-10-16 12:40:18 +0300

updated 2017-10-17 15:24:39 +0300

Edit 2017/10/17: I've just submitted a MR in CalDAV plugin repository. Discussions will happen there on the validity of the correction.

@birefringence and @Maus, I have a scenario for this bug, tell me if this corresponds to your obervations:

  • Event is acknowledge in Thunderbird, and the non standard tag is added and etag changed accordingly.
  • Next sync, etag does not match, so phone is pulling the event from server.
  • When updated on the phone, the non standard tag is not saved locally (this is a bug that I can confirm, I've just added a failing test in the source code). The etag is saved and the modified date is increased.
  • On next update, the plugin sees that there is a modified event locally (because of date changed) and ask the server for a copy to compare. Before 2.1.1.x, the comparison was saying same events because non standard properties are not compared and alarms were not compared. With same event the local version was not upstreamed. After 2.1.1.x, the alarms are compared if any, and a bug (that I corrected in the current testing package) where making the comparison always fails, which means that the local version (without the non standard property) is upstreamed.

So the issue that reappears in 2.1.1.x should happens with this scenario only for events with alarms and the current testing package should hide the bug. Of course, any local modification should make the bug appears also.

I will see with @chriadam what is the best way to properly correct this: currently non standard properties are saved locally only when inserting a new event (non recurring…) but not on update which is broken IMHO.

edit flag offensive delete publish link more


Yes, that exactly matches my observations.

(I still have to try your current testing package, though. Unfortunately, it might take a couple of days until I find some time to do that).

birefringence ( 2017-10-16 23:43:19 +0300 )edit

@Damien Caliste: This sounds profound. I can confirm that I no longer observe the problem with your testing package, contrary to what I wrote above. I created some annoying test events to make sure I notice when it's still broken.

I am impressed, thank you very much!

Maus ( 2017-10-20 18:45:57 +0300 )edit
Login/Signup to Answer

Question tools



Asked: 2017-10-12 23:02:25 +0300

Seen: 305 times

Last updated: Oct 17