Bug 287704 - korganizer does not sync to CalDAV ressource if CalDAV server is not available at program startup
Summary: korganizer does not sync to CalDAV ressource if CalDAV server is not availabl...
Status: RESOLVED FIXED
Alias: None
Product: Akonadi
Classification: Frameworks and Libraries
Component: DAV Resource (show other bugs)
Version: 1.6.0
Platform: OpenSUSE Linux
: NOR normal (vote)
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-11-27 20:43 UTC by Kurt Bennater
Modified: 2011-12-30 13:35 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Kurt Bennater 2011-11-27 20:43:31 UTC
Version:           1.6.0 (using KDE 4.7.3) 
OS:                Linux

Akonadi does not sync to a remote or local CalDAV ressource (in my case, Zarafa 7.0.2) if the CalDAV server was not available at the time korganizer was started. If korganizer is started later than the CalDAV server, the same appointments are synchronized successfully.

I would imagine that this is particularly bad if, e.g., using korganizer on a notebook temporarily without internet connection, and adding appointments. These will not be synced at all. There is probably a connection to Bug 285632.

Reproducible: Always

Steps to Reproduce:
1) Start korganizer, but do not start CalDAV server yet.
2) Within korganizer, add an appointment in a CalDAV ressource.
3) Start CalDAV server.
4) Wait for sync to happen (update calendar).

Actual Results:  
The new entries from step 2) above are not being synced to the CalDAV server.

Expected Results:  
The new entries should be synced indepently of when the remote ressource becomes available.

Even after restarting korganizer, the new entries are not synced to the server. The only thing that helps (AFAIK) is to delete the entries and to re-create them after starting korganizer and the CalDAV in the right order (CalDAV server first).
Comment 1 Grégory Oestreicher 2011-11-29 07:47:28 UTC
Hi Kurt,

Thanks for your report. I'm trying to reach Akonadi devs that may answer whether this case should be handled by the resource or by Akonadi itself. By looking at the IMAP resource code it's doing the same thing, so I'm wondering if this should not be addressed elsewhere than in the resources. More infos later.

Cheers,
Grégory
Comment 2 Grégory Oestreicher 2011-12-20 19:32:24 UTC
Hi Kurt,

Sorry for the delay in responding. The issue is twofold here: the resource cancels the task in this situation, which makes akonadi forget about it, but there's also no way of telling the akonadi to retry at a later time that would not lead to a potential loop while the server is still unavailable.

I'll work around this in the resource, but this will take some time.

Cheers,
Grégory
Comment 3 Kurt Bennater 2011-12-20 20:14:16 UTC
Hi Grégory,

thanks for not forgetting this issue. Does that mean that the IMAP code has to be changed as well? And does this require a new bug report?
(I had understood the idea of akonadi differently: I thought it was akonadi's (and perhaps solid's) responsibility to take care of issues like network availability so that the resource is completely agnostic of such problems. But I get your point.)

Thanks, and a merry Xmas to you,

Kurt
Comment 4 Grégory Oestreicher 2011-12-20 21:07:06 UTC
Hi Kurt,

The resources that declare themselves as needing network connectivity (as is the case for dav, imap, etc.) will be toggled offline if the network connection is shut off. Here it's not the case, it's just the server that is not responding, but network is still here.

For IMAP, if you can reproduce the issue then yes this would be another report. There's not way out of this in Akonadi until at least KDE 4.9 as it's likely to require a new API.

Cheers,
Grégory
Comment 5 Grégory Oestreicher 2011-12-30 13:30:01 UTC
Git commit 3d69bb625a3223ed2d36736ab0a279e2d5e33cb6 by Gregory Oestreicher.
Committed on 30/12/2011 at 14:22.
Pushed by goestreicher into branch 'master'.

Add basic replay cache
This will store and replay changes that were missed in
cases not caught by standard means. The base is to lure
Akonadi into thinking that the changes succeeded while
nothing can guarantee this.

M  +1    -0    resources/dav/common/davutils.cpp
M  +1    -0    resources/dav/resource/CMakeLists.txt
M  +39   -22   resources/dav/resource/davgroupwareresource.cpp
M  +3    -0    resources/dav/resource/davgroupwareresource.h
A  +227  -0    resources/dav/resource/replaycache.cpp     [License: GPL (v2+)]
A  +77   -0    resources/dav/resource/replaycache.h     [License: GPL (v2+)]

http://commits.kde.org/kdepim-runtime/3d69bb625a3223ed2d36736ab0a279e2d5e33cb6
Comment 6 Grégory Oestreicher 2011-12-30 13:35:51 UTC
Git commit 5fcd0a2962c4b2931901c0b6272f0f276f74367b by Gregory Oestreicher.
Committed on 30/12/2011 at 14:22.
Pushed by goestreicher into branch 'KDE/4.8'.

Add basic replay cache
This will store and replay changes that were missed in
cases not caught by standard means. The base is to lure
Akonadi into thinking that the changes succeeded while
nothing can guarantee this.
(cherry picked from commit 3d69bb625a3223ed2d36736ab0a279e2d5e33cb6)

M  +1    -0    resources/dav/common/davutils.cpp
M  +1    -0    resources/dav/resource/CMakeLists.txt
M  +39   -22   resources/dav/resource/davgroupwareresource.cpp
M  +3    -0    resources/dav/resource/davgroupwareresource.h
A  +227  -0    resources/dav/resource/replaycache.cpp     [License: GPL (v2+)]
A  +77   -0    resources/dav/resource/replaycache.h     [License: GPL (v2+)]

http://commits.kde.org/kdepim-runtime/5fcd0a2962c4b2931901c0b6272f0f276f74367b