Re: [Evolution] EWS calendar often out of sync

[Milan Crha <mcrha redhat com>]

On Wed, 2017-06-21 at 14:02 +0200, Michael Hirmke wrote:
> Anything I can do against it?

        Hi,
I can recall only one issue with Exchange 2016 servers, it's
https://bugzilla.gnome.org/show_bug.cgi?id=771370
but that's pretty old and you have that fix in your evolution-ews for
sure.

It would need more debugging , thus if you can, could you file a bug in
GNOME bugzilla:
https://bugzilla.gnome.org/enter_bug.cgi?product=evolution-ews
where we can investigate further, without bothering users on the
mailing list whom are not interested in evolution-ews, please?

There can also depend whether the event is a one-time event, meeting or
recurring event, with or without modified (detached) instances.

As a starter, it would be interesting to run evolution-calendar-factory 
from a command line with EWS debugging on and when the issue happens,
then check the log to see what the server returned. To be sure you have
the local cache in the correct state, remove its content first. The
whole steps would be like this:
a) close evolution
b) stop/kill an evolution-calendar-factory-subprocess process which
   has "--factory ews" as its argument. To list evolution processes
   you can use:
   $ ps ax  | grep evolution
   then kill the process with
   $ kill -TERM PID
   Kill only that single subprocess, not the factory itself, because
   that factory process can be automatically started (notably if you
   run GNOME Shell).
c) remove local cache in ~/.cache/evolution/calendar/
   You can pick particular subfolder, the one for the EWS calendar, or
   remove them all. The worse it'll download data for all calendars again
d) run the calendar factory with the EWS debugging on:
   $ EWS_DEBUG=1 /usr/libexec/evolution-calendar-factory -w &>log.txt
   Your distribution can have is stored elsewhere.
e) wait for ~5 seconds, thus the D-Bus service is fully registered. You
   might also see that the process ID of the process changed in
   the listing of the evolution processes and that there is only one
   evolution-calendar-factory process running.
f) run evolution and use it as before.
g) once you notice the out-of-sync state remember what event it was
   about. It's important to have easier searching in the log. You can
   also save it as iCalendar (in the context menu) and in that file
   is something called X-EVOLUTION-ITEMID, which is similarly
   important as the UID value. Having at least the Summary of the event
   is also good.

Please be aware that the log contains raw communication between the
server and the client, thus private information, which you probably do
not want to share in public (as it'll download your whole calendar,
then it means all the events you have there). Feel free to send such
log only to me, with a reference to that (to be entered) bug report in
the Subject, thus I'd not overlook it in my spam folder.

One note about seeing in Evolution already deleted items from the
server. The local content is updated either periodically (refresh
interval chosen by the EWS backend, not by the user), or, when "Listen
for server change notifications" is enabled, when the server supports
notifications and it had been possible to run it and when the server
sends the notification. You can initiate the refresh manually by right-
clicking the calendar and picking Refresh from the context menu.

        Bye,
        Milan