Closed Bug 464133 Opened 16 years ago Closed 15 years ago

CalDAV deletes against Zimbra server often (always?) fail

Categories

(Calendar :: Provider: CalDAV, defect, P1)

defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: dmosedale, Assigned: Fallen)

References

Details

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

Attachments

(1 file)

      No description provided.
Flags: tb-integration+
I've managed to unhork my Zimbra server account, and now when I try to delete an event from it, I typically get an error dialog box.  The exclamation mark next to the calendar in question appears, and subsequent writes to the calendar seem to fail.  The error console sez:

Error: An error occurred when writing to the calendar MoCo CalDAV! Error code: MODIFICATION_FAILED. Description: 
Source File: file:///Users/dmose/Library/Thunderbird/Profiles/7gmvijow.default/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/modules/calUtils.jsm -> file:///Users/dmose/Library/Thunderbird/Profiles/7gmvijow.default/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/calendar-js/calCalendarManager.js
Line: 944
Summary: CalDAV deletes → CalDAV deletes against Zimbra server often (always?) fail
Priority: -- → P1
Depending on bug 458828, this WFM. Tested against momo's zimbra server.
Depends on: 458828
Dan, since bug 458828 is now fixed, could you please check this again?
Still seems to get the same error, using the most recent build, unfortunately.
Assignee: nobody → daniel.boelzle
WFM against momo zimbra server (URL I am using is like https://mail-test.../dav/dbo/Calendar). However, I think this isn't necessarily an tb-integration issue, but can be investigated towards the release.
Flags: tb-integration?
Flags: tb-integration+
Flags: blocking-calendar1.0+
The way I've been using the tb-integration flag is "I wouldn't want to ship a Thunderbird end-user release containing Lightning until this bug were fixed."  If this bug is at all frequently encountered, I'd say that's very much true: deleting an event is extremely basic functionality.  In principle, if I were the only user encountering this bug, we could ship without fixing it.  

There is, however, the more practical concern that as one of the drivers, there's no way I can reasonably make judgment calls about what remains between the current builds and getting something shippable-with-Thunderbird if I can't use the product for typical calendaring use cases.  As a result, I don't see how this can avoid being tb-integration+, though you're welcome to try and convince me otherwise.

Adding davida to the CC, because I believe he is on the same server instance (MoCo's Zimbra instance) that I am.  David, do you see this behavior?
Flags: tb-integration? → tb-integration+
I never delete, so I don't know. Agree that this would block integration from my POV, until we know who it affects/doesn't affect.
FYI, i just tried, and i can't delete events.  I get a MODIFICATION_FAILED error.
This is WFM for me as well, against mail-test.momo. Is this problem being seen on that Zimbra instance, or another? If they are different instances, are they the same Zimbra rev? There was at one point a Zimbra bug that caused this kind of thing (incorrect http status returned).
This is against the MoCo server.  Pasting "$set:get version" into the Zimbra Web UI search bar shows:

Client Version: 5.0.10_GA_2639.RHEL4
Client Release: 20081003014818
    Build Date: 20081003-0154

What does the MoMo server instance say?
The MoMo Zimbra shows:

Client Version: 5.0.7_GA_2450.RHEL5
Client Release: 20080630192737
    Build Date: 20080630-1935

By setting calendar.debug.log and calendar.debug.log.verbose both to true we could see what status is being returned by the MoCo Zimbra.
Turning on both of those things and then doing a delete results in the following output on stderr:

refresh completed with status 207 at https://mail.mozilla.com/dav/dmosedale@mozilla.com/Calendar/
CalDAV: Unexpected status deleting item: 404
Looks like the "refresh" line was actually generated from an earlier action, and only the 404 showed up after the delete.
Depends on: 469003
Deleting items WFM on latest version gozer has set up (5.0.11_GA_2695.RHEL5-20081117020711).
I have the same problem in Spicebird. The problem seems to be because of the deleteItem method in dav module getting called twice. The first one is succeeding. The second is failing with 404 error. This was obvious from the Darwin calendar server logs:

2009-01-06 21:06:53+0530 [-] [caldav-8009]  [AMP,client] DELETE /calendars/users/admin/calendar/2cbcdc16-cca9-4a29-bb69-b6db180c8d1c.ics HTTP/1.1
2009-01-06 21:06:53+0530 [-] [caldav-8010]  [AMP,client] DELETE /calendars/users/admin/calendar/2cbcdc16-cca9-4a29-bb69-b6db180c8d1c.ics HTTP/1.1
2009-01-06 21:06:53+0530 [-] [caldav-8009]  [AMP,client] Deleting file /home/bunny/calendarserver/CalendarServer/twistedcaldav/test/data/calendars/users/admin/calendar/2cbcdc16-cca9-4a29-bb69-b6db180c8d1c.ics
2009-01-06 21:06:53+0530 [-] [caldav-8010]  [AMP,client] Deleting file /home/bunny/calendarserver/CalendarServer/twistedcaldav/test/data/calendars/users/admin/calendar/2cbcdc16-cca9-4a29-bb69-b6db180c8d1c.ics
2009-01-06 21:06:53+0530 [-] [caldav-8010]  [AMP,client] Not found while deleting file: /home/bunny/calendarserver/CalendarServer/twistedcaldav/test/data/calendars/users/admin/calendar/2cbcdc16-cca9-4a29-bb69-b6db180c8d1c.ics

The double call seems to be because the UI is making call to deleteOccurences twice. Here are the stack traces for both the calls:

#0: function anonymous(aDoNotConfirm=boolean:false, aUseParentItems=boolean:false, aOccurrences=Array:{0}, aCount=integer:1) in <chrome://calendar/content/calendar-views.js> line 182
#1: function onxblkeypress(event=KeyboardEvent:{0}) in <chrome://calendar/content/calendar-multiday-view.xml> line 3775

and

#0: function anonymous(aDoNotConfirm=boolean:false, aUseParentItems=boolean:false, aOccurrences=Array:{0}, aCount=integer:1) in <chrome://calendar/content/calendar-views.js> line 182
#1: function deleteSelectedEvents() in <chrome://calendar/content/calendar-views.js> line 646
#2: function cC_doCommand(aCommand=string:"cmd_delete") in <chrome://calendar/content/calendar-common-sets.js> line 229
#3: doCommand: x-jsd:native-code
#4: function goDoCommand(aCommand=string:"cmd_delete") in <chrome://global/content/globalOverlay.js> line 86
#5: function oncommand(event=XULCommandEvent:{0}) in <chrome://collab/content/collab.xul> line 1

Because of this, the bug does not occur when backspace key, menu item or toolbar item is used for deletion. It only happens with the delete key. The event deletion always succeeds. I have a strong feeling that this is not Spicebird-only behavior.
Good sleuthing.  The fact that the delete key takes a different path than the other UI triggers seems likely to be a bug in and of itself.
I don't see the key handling code in calendar-multiday-view.xml in hg repo. I also could not reproduce the bug in Sunbird trunk build.
(In reply to comment #16)
> Good sleuthing.  The fact that the delete key takes a different path than the
> other UI triggers seems likely to be a bug in and of itself.
I agree. Who should be in charge fixing that?
Assignee: daniel.boelzle → nobody
(In reply to comment #18)
> I agree. Who should be in charge fixing that?

The offending code seems to have been already removed from trunk. Someone who reproduced the bug originally should confirm removal/presence in the trunk.
Another part of the bug that get reproduced when using the unifinder list view seems to been fixed in bug #449573.
The delete key issue was fixed some time between 0.8 and now, this shouldn't be a problem.


Dan, David: I'd like to get this bug finished since its been pending for a while:


* Do deletes work magically by now?
* Which exact server version is failing
  - If this version is not the newest stable, I'm tempted to say this bug is 
    INVALID since its a server bug that has been fixed
  - If this version is the latest stable, please give me access to it.

* Does this happen for any type of event, or is there a difference between
  invitations and normal events
  - If only for invitations, please invite me to a such event on the account
    you've given me (see last point, second subpoint)
(In reply to comment #21)
> * Do deletes work magically by now?

Unfortunately, no.

> * Which exact server version is failing
>   - If this version is not the newest stable, I'm tempted to say this bug is 
>     INVALID since its a server bug that has been fixed

Are you certain this is what's going on, or is that an inference based on comment 18?

> * Does this happen for any type of event, or is there a difference between
>   invitations and normal events

It definitely happens for normal events; not sure about invitations.
Where I'm seeing the error is indeed the older version mentioned in comment 10.
Current theory is that the upgrade of the server that davida and I use will happen next week.
Unfortunately, upgrading the server doesn't seem to have made any difference.
Whiteboard: [needed beta][no l10n impact]
I'm also confirming this bug under the Georgia Tech instance of Zimbra and also against the demo server at testzimbra.com, using latest SVN of Sunbird.  I'm not an administrator for either server so I don't know their version numbers...I'm just trying to connect to my account on them.  This problem does not occur under Evolution.

The same error also seems to happen when trying to snooze or dismiss the reminder on a calendar event.

This behavior happens whether I connect to the Zimbra server using the CalDAV provider or the iCalendar provider.  (With the iCalendar provider, no error is displayed but the requested action does not take place on the server.  Adding an event still works fine under iCalendar.)
Just saw the "$set:get version" trick above.

Georgia Tech is running:
Client Version: 5.0.13_GA_2791.RHEL5_64
Client Release: 20090206112057
    Build Date: 20090206-1128

testzimbra.com is running:
Client Version: 5.0.11_GA_2695.RHEL4_64
Client Release: 20081117020633
    Build Date: 20081117-0211

I realize that the fact that this issue is occurring under iCalendar may possibly be a separate bug...please let me know.  Until today, I have been running a SVN build from late January that has had no problems deleting events from Zimbra under iCalendar.  Today I updated to the latest SVN and it's the first time I noticed it doing this under iCalendar.  Then I discovered CalDAV support for Zimbra and tried connecting with that, but I'm seeing the same thing all of you are.  Looks like the CalDAV issue has been going on much longer though.
Forgot to mention...  this applies to tasks as well as calendar events.

Sorry for all the separate messages.
I applied for a testzimbra.com account today, lets see when my mail server actually delivers the email.
You shouldn't have to wait for an e-mail (at least if you click the "Skip Registration, Go To Demo" button -- I don't know what happens when you click thet other button).  Just enter the CAPTCHA and then it will immediately create your account and log you into it.  The e-mail in your testzimbra.com inbox will have your username and password for connecting to that inbox in the future and for connecting externally via CalDAV, etc.
aaaah finally I found the problem!!!

The following URL will work: 

http://testzimbra.com/dav/zm308vxujp/Calendar

The following URL will not work:

http://testzimbra.com/dav/zm308vxujp@testzimbra.com/Calendar


The problem lies in the way we strip the path component from the calendar id. Until now we have been using the length of the uri's path /dav/zm308vxujp@testzimbra.com/Calendar/, but the href's returned from zimbra contain just /dav/zm308vxujp/Calendar.

Not sure how to best fix this yet, but working on it.
Great work...  if I subscribe to the shorter URL version, that seems to fix it for me too under Georgia Tech's server.

But if Zimbra is telling users to use the longer version of the CalDAV URL (as displayed in the Share Calendar dialog), but the software is returing URIs with the shorter version...  isn't that a Zimbra issue?

I'm asking because I just checked and this problem does not happen on 01.com's Zimbra instance (paid).  This is because it has the mail server running on mail.01.com, but its accounts are set up within Zimbra to be in the domain zimbra.01.com.  Meaning that when you log in, you have to enter a full e-mail address ending in @zimbra.01.com or the server doesn't recognize the account (really annoying honestly).  So in this case Zimbra won't even be able to access the CalDAV calendar if you leave off the @domain part in the URI.
But ... I guess I can see how this could be a Sunbird problem though, if it should just be handling whatever URI the server gives it back.  I dunno.  I haven't worked with either of these projects.  Just wanted to throw that out.
Attached patch Fix - v1 β€” β€” Splinter Review
This should take care. I also noticed a bug when the server redirects (which testzimbra.com did) and added some more code to find such problems quicker in the future.
Assignee: nobody → philipp
Status: NEW → ASSIGNED
Attachment #366210 - Flags: review?(ssitter)
Attachment #366210 - Flags: review?(ssitter) → review?(browning)
Comment on attachment 366210 [details] [diff] [review]
Fix - v1

review should be done by someone familiar with caldav provider
I'm sure zimbra could be a bit more forgiving here by not returning a 404 when the default domain is appended, but since the fix on the Calendar side is quite easy, I think we should go for it.

Please file a zimbra bug so they can consider doing so.
Found and updated related Zimbra bug 30263:  http://bugzilla.zimbra.com/show_bug.cgi?id=30263
Comment on attachment 366210 [details] [diff] [review]
Fix - v1

Daniel, if you have time before Bruno does, please feel free to review.
Attachment #366210 - Flags: review?(dbo.moz)
Comment on attachment 366210 [details] [diff] [review]
Fix - v1

bruno said he'd take care of the review, cancelling request.
Attachment #366210 - Flags: review?(dbo.moz)
Comment on attachment 366210 [details] [diff] [review]
Fix - v1

looks, works good. =browning
Attachment #366210 - Flags: review?(browning) → review+
Pushed to comm-central <http://hg.mozilla.org/comm-central/rev/4ce52ce2c749>

-> FIXED
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
OS: Mac OS X → All
Hardware: x86 → All
Resolution: --- → FIXED
Target Milestone: --- → 1.0
Target Milestone: 1.0 → 1.0b1
You need to log in before you can comment on or make changes to this bug.