Syncevolution chokes on one calendar entry, doesn't say which, doesn't allow to skip, doesn't show actual server's complaint

[Patrick Ohly]

On Mon, 2018-02-12 at 10:35 +0100, Alain Knaff wrote:
> Hi,
> 
> When trying to use synccalendar, I occasionally get the following:
> 
> [INFO @aev] operation temporarily (?) failed, going to retry in 5.0s
> before giving up in 298.7s: REPORT 'check for items': bad HTTP
> status: <status 1.1, code 503, class 5, Service Unavailable>
>
> And then repeats the message with ever growing delays.

503 indicates a temporary error, so the WebDAV layer is correctly
retrying it for a while. If that problem persists for certain
operations, then the server operator and/or developer needs to
investigate that.

> Apparently, sync-evolution or the server doesn't like a certain
> calendar 
> entry, and rather than move on to the next, just gets stuck on it.

Primarily this is the server. It could of course also be caused by bad
data being sent by SyncEvolution, but then the server should outright
reject it instead of reporting a temporary error.

> Sometimes killing syncevolution, and then starting it again fixes
> the 
> issue, and sometimes not. Btw, to kill syncevolution, just using
> Ctrl-C
> doesn't do the job, you've actually got to use the kill command from
> another terminal session, or use Ctrl-Z and then kill.

You should get a message that you need to use Ctrl-C twice to abort
immediately. Otherwise it tries to suspend the sync, which is less
intrusive and may allow resuming it the next time.

But I just tried that and noticed that there is no such message. I'm
testing a fix. Ctrl-C twice however should work.

> May I suggest three small changes to make this issue much less
> painful:
> 
> 1. When such a thing occurs, actually say *which* calendar entry
> causes 
> this. For most practical cases date, time and title should be enough
> to 
> uniquely identify the entry and allow the user to "manually" transfer
> it 
> (i.e. manually delete it on phone, manually change/create it on
> server, 
> and sync it back), or even to allow him to understand what is
> causing 
> this.

This isn't as easy to implement as it seems. The layer which runs into
the temporary error has no idea what item it is dealing with, and in
some cases the "offending" calendar entry might not even be in the
operation (for example, a PUT which removes some item from a larger
set).

Once the operation times out, the upper layers should print a proper
ERROR message about the failed items. As the error in your case isn't
really "temporary" and retrying the request doesn't make it go away,
you might want to reduce the RetryDuration in your target configuration
(the WebDAV side).

> 2. The message just echoes the HTTP Status line, and not the rest of
> the 
> contents of the server's error page. Maybe the server (MS Exchange
> via 
> davmail) does indeed explain what's the issue with that calendar
> entry? 
> Bad status? Bad Reminder options? etc.? Impossible to know easily,
> as 
> nowadays most server use HTTPs and so even tcpdump wouldn't be any
> help.

How should SyncEvolution render the error response? Quite often it is
HTML. There's also the risk of spewing a lot of text to the console.
The INFO message is intentionally a single line.

If someone wants to know more, they should run with a high log level
(like 10) and look at the HTML log file for a failed sync to learn more
about the individual HTTP requests.


> 3. Rather than just retrying forever, syncevolution should skip over
> the 
> entry, move on to the next, and repeat in the final summary message
> that 
> such-and-such entry was skipped (and identify the entry as described
> in
> point 1)

It shouldn't retry forever. The default is 5 minutes. Remember that
this is for the case where the server really is loaded. Giving up a
sync too soon would just make the situation worse because the next sync
then might have to be done in slow mode, so IMHO it makes sense to try
for a while.

> Other question: I run syncevolution on a BQ Aquaris E5 phone with
> Ubuntu 
> Touch. Ubuntu no longer supports touch, however, and apt-get upgrade
> has 
> stopped working for a while. So I'm stuck at version
> 1.5.1+15.04.20160706-0ubuntu1
> 
> However, UBports has taken up this task, and I suppose they've got a 
> repository somewhere from which to get updates from them.
> Unfortunately 
> there site is silent on that issue, and only describes how to
> install 
> ubports from scratch on a new device, and not how to upgrade an
> existing 
> Ubuntu touch device. Do you by chance know what to enter into 
> /etc/apt/sources.list to get updates from UBports rather than from 
> Ubuntu?

Sorry, I'm not familiar with Ubuntu phones (never had one).

> Third question: due to this whole dropped support issue, I'm in the 
> market for a new phone, and it will either be stock Android or
> Lineage 
> OS (due to current lack of other Linux alternatives :-( ). Does 
> syncevolution work on these two OS'es?

No, but there are other CalDAV/CardDAV clients, or you can sync the
phone directly with Exchange.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.