641665 - Caldav synchronization error in cached calendars

Status: RESOLVED FIXED

(Calendar :: Provider: CalDAV, defect)

Description

[Fco. Jose Mulero]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_6; es-es) AppleWebKit/533.20.25 (KHTML, like Gecko) Version/5.0.4 Safari/533.20.27
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; es-ES; rv:1.9.2.11) Gecko/20101013 Ubuntu/9.04 (jaunty) Firefox/3.6.11 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; es-ES; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9

If thunderbird is closed before a cached calendar is fully sincronized (not all events are retrieved from server) if nothing is changed in the server, the client don't request the rest of events.

Reproducible: Always

Steps to Reproduce:
1. Create a new cached caldav calendar over a high collection (1000 events for example)
2. Close Thunderbird before the load  finished.
3. Open Thunderbird and reload remote calendars.
Actual Results:  
The caldav scheduling don't follow, don't try to recover the rest of events.

Expected Results:  
Calendar continues loading events from server.

Its posible that the "ctag" of the caldav collection is saved before all the calendar reports are finished.

Comment 1

[Fco. Jose Mulero]

Attachment: Patch over comm-central

This patch includes a posible solution to the bug. This solution consists in use a tentative ctag until the updateItems function finalize. When this function finalizes correctly calls to finalizeUpdatedItems, where the ctag is confirmed and saved.

Comment 2

[Simon Vaillancourt]

Comment on attachment 519871 [details] [diff] [review]
Patch over comm-central

Very sorry for the long delay in reviewing this.  I think you have the right idea in how to fix this issue, however, I think the usage of mOldCtag should be completely removed in favor of the new mProposalCtag, please submit another patch and I will review it faster this time :)

Thanks.

Comment 3

[Jaco Kroon]

Attachment: updated mProposalCtag patch

Does this look more like what you're after?

I still get a case where this doesn't do what I want, if the calendar retrieval fails due to an internal bug (ie, not all items actually load, but did get an appropriate 207 response) then things still go haywire in that unless there is actually a change on the server the client won't try to retrieve the calendar again.

Comment 4

[Jaco Kroon]

Ok, I just noted that my whitespace is stuffed in the attached patch, not going to roll a new one without also fixing the issue.  As it stands it seems calDav_finalizeUpdatedItems gets called irrespective of whether there was actually updated items or not, at least in my case (the initial sync) none of the items from the server gets loaded into the local calendar (Warning: CalDAV: Fatal Error doing multiget for JKroon), but still when next I try and force a resync I get "CalDAV: ctag matches, no need to fetch data for calendar JKroon".  The output from the finalizeUpdatedItems entry code:

aChangeLogListener=undefined
calendarURI=http://atlantis.local.uls.co.za/caldav/jkroon/ 
iscached=false
this.mQueuedQueries.length=13

How can I detect this case and deal with it accordingly (by either doing a fail-all and not proceeding with the sync, failing it entirely), or possibly by stopping at the first failure and "calculating" a ctag at that point?

Comment 5

[Jaco Kroon]

Hi, just FYI, the "success" came from a bug in a different section as per bug 704012#c6 - so I think this patch (bar the whitespace) should be OK.

Comment 6

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Attachment: Fix - v3

I've updated the patch to the latest comm-central. It can be tested with a server that doesn't use webdav-sync, but uses ctags. For example, Zimbra servers fulfill this criterion, so if you have a yahoo account you might be able to test it.

Comment 7

[Matthew Mecca [:mmecca]]

Comment on attachment 8394775 [details] [diff] [review]
Fix - v3

Untested, but looks good codewise. r=mmecca

Comment 8

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/comm-central/rev/043437216602