Closed Bug 497095 Opened 15 years ago Closed 13 years ago

faulty operations retains the new ctag

Categories

(Calendar :: Provider: CalDAV, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: WSourdeau, Assigned: Fallen)

Details

(Whiteboard: [needed beta][no l10n impact])

Attachments

(1 file, 1 obsolete file)

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; fr; rv:1.9.0.10) Gecko/2009042805 Iceweasel/3.0.9 (Debian-3.0.9-1)
Build Identifier: 20090608035852

Since the ctag is fetched at the beginning of the chain of requests and memorized before the rest of the operations are completed, a server crash will prevent further client updates as well. The attached patch fixes this, by reverting the ctag back to its initial value in case of an error.

Reproducible: Always
Attached patch the patch (obsolete) — — Splinter Review
Please review this as I may have forgotten points in the code where errors are handled. A priori I covered them all but I may have missed some.
Attachment #382289 - Flags: review?
Assignee: nobody → WSourdeau
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
OS: Linux → All
Hardware: x86 → All
Attachment #382289 - Flags: review? → review?(philipp)
Comment on attachment 382289 [details] [diff] [review]
the patch

I think there are some other paths, or I don't understand in which cases this is needed and in which cases its not.

Example:

getUpdatedItems => (mDisabled == true) -> checkDavResourceType => (error happens) -> completeCheckServerInfo => reportDavError => ?

Quite possible that I just don't quite understand the situation. I'd appreciate a more detailed description and if possible some steps to reproduce.
Attachment #382289 - Flags: review?(philipp) → review-
Here is the current workflow:

 fetch ctag -> (has changed?) -yes-> save ctag, fetch etags -> (added/deleted/modified?) -yes-> fetch calendar-data -> save calendar-data

Since the ctag is saved as soon as it is received, any further steps where a crash or a network error would occur would not be retried afterwards since the ctag was saved just after comparison. That is the problem, while with my fix, the ctag is confirmed only after all the steps have been completed successfully.
Flags: blocking-calendar1.0+
Whiteboard: [not needed beta][no l10n impact]
Whiteboard: [not needed beta][no l10n impact] → [needed beta][no l10n impact]
Attached patch Fix - v2 — — Splinter Review
New version of the patch. I've tried to follow all paths that are taken in getUpdatedItem, it seems everything ends in notifyGetFailed. I hope I didn't forget any cases.
Attachment #503787 - Flags: review?(nomisvai)
Attachment #382289 - Attachment is obsolete: true
Assignee: WSourdeau → philipp
Whiteboard: [needed beta][no l10n impact] → [needed beta][no l10n impact][needs review]
Comment on attachment 503787 [details] [diff] [review]
Fix - v2

looks good
Attachment #503787 - Flags: review?(nomisvai) → review+
Pushed to comm-central <http://hg.mozilla.org/comm-central/rev/6e981b8218f7>
-> FIXED
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → Trunk
Whiteboard: [needed beta][no l10n impact][needs review] → [needed beta][no l10n impact]
Backported to comm-1.9.2 <http://hg.mozilla.org/releases/comm-1.9.2/rev/c96927a7170d>
a=philipp
Target Milestone: Trunk → 1.0b3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: