Closed
Bug 497095
Opened 15 years ago
Closed 13 years ago
faulty operations retains the new ctag
Categories
(Calendar :: Provider: CalDAV, defect)
Calendar
Provider: CalDAV
Tracking
(Not tracked)
RESOLVED
FIXED
1.0b3
People
(Reporter: WSourdeau, Assigned: Fallen)
Details
(Whiteboard: [needed beta][no l10n impact])
Attachments
(1 file, 1 obsolete file)
2.40 KB,
patch
|
nomisvai
:
review+
|
Details | Diff | Splinter Review |
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
Reporter | ||
Comment 1•15 years ago
|
||
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?
Updated•15 years ago
|
Assignee: nobody → WSourdeau
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
OS: Linux → All
Hardware: x86 → All
Updated•15 years ago
|
Attachment #382289 -
Flags: review? → review?(philipp)
Assignee | ||
Comment 2•15 years ago
|
||
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-
Reporter | ||
Comment 3•15 years ago
|
||
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.
Assignee | ||
Updated•14 years ago
|
Flags: blocking-calendar1.0+
Whiteboard: [not needed beta][no l10n impact]
Assignee | ||
Updated•14 years ago
|
Whiteboard: [not needed beta][no l10n impact] → [needed beta][no l10n impact]
Assignee | ||
Comment 4•13 years ago
|
||
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)
Assignee | ||
Updated•13 years ago
|
Attachment #382289 -
Attachment is obsolete: true
Assignee | ||
Updated•13 years ago
|
Assignee: WSourdeau → philipp
Assignee | ||
Updated•13 years ago
|
Whiteboard: [needed beta][no l10n impact] → [needed beta][no l10n impact][needs review]
Comment 5•13 years ago
|
||
Comment on attachment 503787 [details] [diff] [review] Fix - v2 looks good
Attachment #503787 -
Flags: review?(nomisvai) → review+
Assignee | ||
Comment 6•13 years ago
|
||
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
Assignee | ||
Updated•13 years ago
|
Whiteboard: [needed beta][no l10n impact][needs review] → [needed beta][no l10n impact]
Assignee | ||
Comment 7•13 years ago
|
||
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.
Description
•