Open
Bug 1272564
Opened 8 years ago
Updated 2 years ago
"Calendar entry recently changed on server message" when closing a reminder
Categories
(Calendar :: Provider: CalDAV, defect)
Tracking
(Not tracked)
NEW
People
(Reporter: tessarakt, Unassigned)
Details
Attachments
(1 file)
20.79 KB,
image/png
|
Details |
I am using Thunderbird 45.1 (beta) with Lightning 4.7.1b1. I am accessing an Exchange server via Davmail 4.7.2-2427 (i.e. using CalDAV between Lightning an Davmail). When I try to close the reminder for an appointment in Lightning, I always (or almost always? I'm not 100% sure) get a dialog box like in the attachment. The English translation is roughly: "The calendar entry has been recently changed on the server. Submitting this change will overwrite the changes on the server. [Discard changes and reload] [Submit changes anyway]" The same behaviour has been confirmed by two people on the Davmail user mailing list. We speculated that it has something to do with another client (Outlook) modifying some details of the event. In my case, it might be the calendar application on a Windows phone. And some more speculation from my side about what's happening in Lightning: So I am dismissing an alarm for an event. Apparently the status for that alarm is stored inside the calendar event, so Lightning modifies that representation and causes it to be stored. The code that stores the data then notices the conflict and displays the dialog, which is quite inconclusive. IMO it should be quite easy to just load the updated data and re-perform the original action (i.e. dismiss the alarm), but apparently the error is not propagated back to that code ... For a start, it might help to see how the entry on the server has actually changed ...
Reporter | ||
Comment 1•8 years ago
|
||
Reporter | ||
Comment 2•8 years ago
|
||
See also bug 1022655.
Comment 3•8 years ago
|
||
The bug you referenced is not related to the reminder issue and davmail, so it's most probably unrelated. Can you please enable calendar.debug.log and calendar.debug.log.verbose in the advanced preferences and post the messages you get when reproducing the issue? If you want to obfuscate some data for privacy reasons, please make sure to not change the information structure. Do you have access to the Davmail server log? It may unveil best what's going on. If not and to exclude third party impact on the serverside event, can you disconnect your other clients and try to reproduce the issue?
Flags: needinfo?(blog)
Reporter | ||
Comment 4•8 years ago
|
||
I had to exchange my phone recently, and I have not set up the calendar on the new phone yet. It seems that the issue has not occurred again since. However, I was able to reproduce the issue using Outlook Web Access (OWA). Steps which did not trigger the issue: 1. Create event in OWA, set reminder 0 minutes before. 2. Sync calendar in Lightning. 3. Keep OWA open. 4. Wait ... -> A reminder appears in Lightning and OWA. 5. Click "Close" (or is it "Dismiss"?) in Lightning. -> No error message - however, even after reloading, the reminder still appears in OWA ... Step which DID trigger the issue: 1. Create event in OWA, set reminder 0 minutes before. 2. Sync calendar in Lightning. 3. Keep OWA open. 4. Wait ... -> A reminder appears in Lightning and OWA. 5. Clock Close/Dismiss in OWA. 5. Click "Close" (or is it "Dismiss"?) in Lightning. -> The error message occurs. I will now enable logging and try again.
Comment 5•8 years ago
|
||
I don't see a difference between both approaches of STR - am I missing something?
Reporter | ||
Comment 6•8 years ago
|
||
I looked into the Davmail log. It seems Lightning sends a PUT request with an If-Match header. I don't really know which part of the body actually indicates the dissmissal of the reminder, so I post it here in full. PUT /users/Jens.XY.Mueller%40invalid.invalid/calendar/deleted_deleted%3D.EML HTTP/1.1 [some more headers] If-Match: 2016-05-16T19:48:53Z UID:040000008200E00074C5B7101A82E00800000000EA742EFAABAFD10100000000000000 0010000000D6A23B57D339D648AAE7F32F305DEBB9 SUMMARY:TEST PRIORITY:5 STATUS:CONFIRMED X-MOZ-LASTACK:20160516T195009Z DTSTART;TZID=Europe/Berlin:20160516T215000 DTEND;TZID=Europe/Berlin:20160516T215100 DESCRIPTION;LANGUAGE=de-DE:\n CLASS:PUBLIC TRANSP:OPAQUE SEQUENCE:0 LOCATION;LANGUAGE=de-DE:TEST X-MICROSOFT-CDO-APPT-SEQUENCE:0 X-MICROSOFT-CDO-OWNERAPPTID:2114290154 X-MICROSOFT-CDO-BUSYSTATUS:BUSY X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY X-MICROSOFT-CDO-ALLDAYEVENT:FALSE X-MICROSOFT-CDO-IMPORTANCE:1 X-MICROSOFT-CDO-INSTTYPE:0 X-MICROSOFT-DISALLOW-COUNTER:FALSE X-MOZ-GENERATION:1 BEGIN:VALARM ACTION:DISPLAY TRIGGER;VALUE=DURATION:PT0S DESCRIPTION:REMINDER END:VALARM END:VEVENT END:VCALENDAR Exchange Web Services then reply with: HTTP/1.1 412 Precondition Failed
Reporter | ||
Comment 7•8 years ago
|
||
(In reply to MakeMyDay from comment #5) > I don't see a difference between both approaches of STR - am I missing > something? In the first STR, I immediately dismissed in Lightning. In the second STR, I dismissed the event in OWA first.
Flags: needinfo?(blog)
Reporter | ||
Comment 8•8 years ago
|
||
(In reply to MakeMyDay from comment #3) > Can you please enable calendar.debug.log and calendar.debug.log.verbose in > the advanced preferences and post the messages you get when reproducing the > issue? Ah, I need to restart TB and then I will see the messages in the Error Console, right? Will try this now.
Reporter | ||
Comment 9•8 years ago
|
||
When I press "Dismiss" on the reminder, I see the following messages in the error console: CalDAV: send: BEGIN:VCALENDAR PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN VERSION:2.0 BEGIN:VTIMEZONE TZID:Europe/Berlin BEGIN:DAYLIGHT TZOFFSETFROM:+0100 TZOFFSETTO:+0200 TZNAME:CEST DTSTART:19700329T020000 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=3 END:DAYLIGHT BEGIN:STANDARD TZOFFSETFROM:+0200 TZOFFSETTO:+0100 TZNAME:CET DTSTART:19701025T030000 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 END:STANDARD END:VTIMEZONE BEGIN:VEVENT LAST-MODIFIED:20160516T200610Z DTSTAMP:20160516T200610Z UID:040000008200E00074C5B7101A82E008000000008F63082CAEAFD10100000000000000 0010000000268F820698DD874092BE49A615404C59 SUMMARY:TEST PRIORITY:5 STATUS:CONFIRMED X-MOZ-LASTACK:20160516T200610Z DTSTART;TZID=Europe/Berlin:20160516T220600 DTEND;TZID=Europe/Berlin:20160516T220700 DESCRIPTION;LANGUAGE=de-DE:\n CLASS:PUBLIC TRANSP:OPAQUE SEQUENCE:0 LOCATION;LANGUAGE=de-DE:TEST X-MICROSOFT-CDO-APPT-SEQUENCE:0 X-MICROSOFT-CDO-OWNERAPPTID:2114289807 X-MICROSOFT-CDO-BUSYSTATUS:BUSY X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY X-MICROSOFT-CDO-ALLDAYEVENT:FALSE X-MICROSOFT-CDO-IMPORTANCE:1 X-MICROSOFT-CDO-INSTTYPE:0 X-MICROSOFT-DISALLOW-COUNTER:FALSE X-MOZ-GENERATION:1 BEGIN:VALARM ACTION:DISPLAY TRIGGER;VALUE=DURATION:PT0S DESCRIPTION:REMINDER END:VALARM END:VEVENT END:VCALENDAR CalDAV: recv: => Yes, it's really only "CalDAV: recv: ", nothing more! Another strange thing: The error message is modal to the TB main window, not the reminder dialog ... So I can press "Dismiss" a second time while the error message is shown ...
Comment 10•8 years ago
|
||
Ok, thanks for providing the logs. This is something we cannot overcome easily. The only short term solution would be to avoid such race conditions. Whether or not Exchange uses also the event to store the information about dismissing a reminder as Lightning does (we use the X-MOZ-LASTACK property you can see in the event), the Etag seems to have been invalidated by the Davmail server, so the dismissal must fail, because we rely on updating the event. A solution without changing the entire architecture might be to try to re-retrive the event in case of a 412 error for the reminder use case and dismiss/snooze unconditionally once again without further user interaction. But this would probably only be an option for CalDAV and not for ICS calendars due to the expected load time and would need more investigation.
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•