Ask / Submit

CalDAV calendar: msyncd fails when updating event with exceptions [answered]

asked 2019-03-15 13:01:13 +0300

Maus gravatar image

updated 2019-03-25 21:55:59 +0300

Update 2019-03-25: the modified package makes my calendar usable. I close this question as I expect the solution to be delivered in a future OS update.

Update 2019-03-21: a malfunction with interpreting event exceptions has been found by @Damien Caliste. I'm testing a modified package at the moment which addresses part of the aspects of the malfunction.

I experience problems with a CalDAV account. After account creation, an event with lots of exceptions is immediately uploaded back to the server (msyncd logs Uploading exception modification via series update for local modification), but this upload fails with Network request failed with QNetworkReply::NetworkError: 299 and subsequent syncs always fail, because they first try to upload this exception modification again.

This obviously makes this calendar unusable. Interestingly, if I use EAS as backend for this calendar, the sync is also broken. I don't know if the same event causes it to fail, though. So probably the internal representation of events with exceptions may be the problem here.

For the record, I'm on SFOS 3.0.1 at this moment.

edit retag flag offensive reopen delete

The question has been closed for the following reason "the question is answered, an answer was accepted" by Maus
close date 2019-03-25 21:56:19.030145


Two things:

  • in the coming 3.0.2 release, there is a fix for spurious detection of modified exception, so it may solve your issue.
  • I can give a look if you can gather logs, and particularly the ICS data that is tried to be up-synced to the server.
Damien Caliste ( 2019-03-15 13:33:43 +0300 )edit

@Damien Caliste, thank you very much for this information. I've sent you an email with details from the msyncd log. Your help is very much appreciated!

Maus ( 2019-03-15 16:15:28 +0300 )edit

Ok, got it. Thanks. I'm investigating…

Damien Caliste ( 2019-03-15 17:25:26 +0300 )edit

The fact that the event is detected as modified should be addressed by the coming fix in 3.0.2. But I'm concerned by the fact that the "modified" event cannot be uploaded. The actual error is a 412 HTTP error, meaning that the If-Match condition is not fullfilled. Looking at the condition, I'm suprised to see If-Match :, it is supposed to have the form If-Match : "1572-123456789".

Sorry to ask you again, may you give a look in the log, the one when you first sync the account. There should be a Process REPORT response for server path sentence followed by the response from the server with all the ICS data for every events. May I ask you to send me a sample of this reply, particularly the part with the etag but also with the ICS data ? Thank you in advance.

Damien Caliste ( 2019-03-15 17:47:02 +0300 )edit

I've supplied a PROCESS response by email.

Maus ( 2019-03-16 23:02:22 +0300 )edit

1 Answer

Sort by » oldest newest most voted

answered 2019-03-25 11:31:31 +0300

updated 2019-03-27 14:21:04 +0300

As mentioned in the comments, the logs provided by @Maus put a highlight on two issues:

  • a spurious upsync of an event with persistent exceptions
  • an issue with CALDAV implementation during each down sync when there are persistent exception to an event (the persistent exception are reported with a different etag than the main event, confusing the sync process on device).

The first issue was an incomplete fix of this TJC issue, and the package @Maus is currently testing corresponds to the code in the following merge request. It's not solving the second issue though… but it should minimise its annoying behaviour. It should also save some useless round trip with the server for everyone when exceptions are updated on server.

2019-03-27 edit: the second issue was indeed a bug in open-xchange implementation. I've submitted a bug report(the bug tracker is not public, but creating an account is simple) with details on the request and responses for events with excepitions. One developper confirmed the bug two days after and now the bug is fixed upstream and should be released in 7.10.2 product from open-xchange. Nice support. Hopefully is closely following upstream releases for their backend.

edit flag offensive delete publish link more


The patched package by @Damien Caliste allows me to use the Calendar in read-only mode, which is very much better than a "sync-once-change-never" model. Thank you very much, Damien!

Maus ( 2019-03-25 21:41:14 +0300 )edit

Question tools



Asked: 2019-03-15 13:01:13 +0300

Seen: 172 times

Last updated: Mar 27 '19