We have moved to a new Sailfish OS Forum. Please start new discussions there.
10

[3.2.1] New CalDav Calendars not syncing anymore (XA2): "Error saving updated persistent occurrence"

Tracked by Jolla (In release)

asked 2019-12-14 21:19:25 +0200

Sebix gravatar image

updated 2019-12-20 15:21:28 +0200

On a XA2 device with 3.2.1 I want to set up CalDav calendars syncing with Nextcloud. I can create the account in the settings, which works fine, it shows the two available calendars. The calendar app however does not show any events. In the "Manage calendars" menu I further only see the first one of my two calendars.

Dec 14 21:17:13 Sailfish caldav-client[9345]: [W] unknown:0 - error: could not dissociate occurrence from recurring event: "[UUID]" "2019-11-0
1"
Dec 14 21:17:13 Sailfish caldav-client[9345]: [W] unknown:0 - Error saving updated persistent occurrence of resource "/nextcloud/remote.php/dav/calendars/[username]/[calendarname]/[UUID].ics" : "2019-11-01"
Dec 14 21:17:13 Sailfish caldav-client[9345]: [W] unknown:0 - Unable to write notebook changes for notebook at index: 0
Dec 14 21:17:13 Sailfish caldav-client[9345]: [W] unknown:0 - CalDAV sync failed: 401 "unable to write notebook changes"

Setting up the same calendar on a Jolla 1 with 3.2.0 works fine.

edit retag flag offensive close delete

Comments

1

I experience this as well. CardDAV is working well but CalDAV seems broken. :I

megalith ( 2019-12-15 01:03:13 +0200 )edit
3

Sorry for this, I'll look for it next week. Try to see what changes make an exception impossible to create.

Damien Caliste ( 2019-12-15 12:16:46 +0200 )edit

@damien: Thanks. I tried to work around by removing the calendar event (all occurrences) from the server, but that did not make a difference. What do you mean by "Try to see what changes make an exception impossible to create."?

Sebix ( 2019-12-15 12:22:58 +0200 )edit

That's the reported error. Cannot dissociate occurrence .So that's the lead. Sorry for the inconvenience.

Damien Caliste ( 2019-12-15 12:35:28 +0200 )edit

I could share the ics file in question with you on a private channel. The error appears for events with different recurrences like monthly and bi-weekly.

Sebix ( 2019-12-15 12:54:16 +0200 )edit

2 Answers

Sort by » oldest newest most voted
13

answered 2019-12-18 11:39:42 +0200

updated 2019-12-19 11:56:40 +0200

Ok, I've found the regression. In a nutshell, the ICS data may be faulty and the importer in 3.2.1 became more strict.

Let's look at the ICS data :

BEGIN:VEVENT
UID:9e3e9495-7fca-46b1-9ae4-207f3a1a9148
EXDATE;VALUE=DATE:20190724
RDATE;VALUE=DATE:20190724
DTSTART;VALUE=DATE:20190724
DTEND;VALUE=DATE:20190725
END:VEVENT

It is defining an event that can recurs (it has an rdate defined), but with an exception for July 24th (meaning that there is _no_ occurrence that day). Now, the ICS data also contains information for an exception, defined with a recurrence id like RECURRENCE-ID;VALUE=DATE:20190724. Such an exception cannot be created since there is a test like if !recursOn(recurrenceId) fails in mKCal code. The difference is now, the result of this test is not ignored anymore. @Sebix, you may check that the exceptions are not handled properly on your Jolla1 @ 3.2.0 to validate this hypothesis.

I see two ways to correct this:

  • ignore the error as before if an exception cannot be created.
  • remove the faulty exdate from the list of exception dates if an occurrence is provided at this specific date, so mKCal is happy.

I need to check also the RFC for that matter, if we can have a recurrence id that is matching an exdate or not. But clearly the current code and the one from 3.2.0 does not allow it (even if before the error was silently ignored).

I've compiled a version of the Buteo CalDAV plugin available in 3.2.1 with the behaviour of ignoring dissociation errors like before as a quick fix, see buteo-sync-plugin-caldav-0.1.56-1.armv7hl.rpm.gz. This corresponds to the code available in this git branch : https://git.sailfishos.org/dcaliste/buteo-sync-plugin-caldav/tree/fix

I've just proposed a patch in SailfishOS implementing the second possibility: removing the offending exdate and adding the exception. I've compiled this particular commit on top of version 0.1.56 from 3.2.1, see buteo-sync-plugin-caldav-0.1.56-1.armv7hl.rpm.gz. This should display the exception on device, while the previous quick fix is not (and any previous version is not neither). But it may have the drawback that modifying the recurring event on device may confuse the server after up-sync, because the faulty exdate value will not be added on up-sync. This depends on the server, I've no idea.

edit flag offensive delete publish link more

Comments

First, thanks for looking into this! Silently ignoring the error is way better than a synchronization fail. FTR: The ICS data was created and handled by the programs MS Outlook and Thunderbird.

ignore the error as before if an exception cannot be created.

Plus optionally show an error (in red text) in the events' view for the erroneous date? (Could be more or less easy to implement)

remove the faulty exdate from the list of exception dates if an occurrence is provided at this specific date, so mKCal is happy.

That requires displaying the error, suggestions (and solution) to the user, probably not that easy.

Sebix ( 2019-12-18 11:46:30 +0200 )edit
1

Showing an error in the event view is not possible at all with the current framework I think. There is no way to mark the event as faulty.

Removing the faulty exdate from the base event can be done by the plugin on importation without requesting user opinion if an occurrence is provided. As far as I understand the RFC, it's faulty and since the occurrence is there, we know which faulty part to remove.

I'll also discuss with Chris Adams about the best choice to adopt to correct this.

Damien Caliste ( 2019-12-18 11:55:02 +0200 )edit

If you need expert help, you should ask Evert Pot. He is the author of SabreDAV, the "engine" behind ownCloud/Nextcloud and has helped me and others several time on the Contacts and Calendar apps. There's not the thing he doesn't know about VCARD, VEVENT, VTODO, VNOTE, VJOURNAL, VWHATEVER ;)

And calendars are notoriously complicated to work with.

Tanghus ( 2019-12-18 11:55:55 +0200 )edit
1

After installing the provided hotfix rpm, I can sync the calendars again. Thanks!

Sebix ( 2019-12-18 12:23:41 +0200 )edit
2

Is the patch also part of the 3.2.1.20 release?

Sebix ( 2019-12-20 00:02:26 +0200 )edit
1

answered 2020-04-27 10:28:15 +0200

jovirkku gravatar image

This should be fixed in OS release 3.3.0.

edit flag offensive delete publish link more
Login/Signup to Answer

Question tools

Follow
10 followers

Stats

Asked: 2019-12-14 21:19:25 +0200

Seen: 1,170 times

Last updated: Apr 27 '20