Open Bug 1717401 Opened 5 years ago Updated 10 days ago

Accepting invitation before calendar sync fails (Status 80004005) - Thunderbird should perform a sync of the target calendar before trying to make changes to it.

Categories

(Calendar :: E-mail based Scheduling (iTIP/iMIP), defect)

Thunderbird 78
defect

Tracking

(Not tracked)

ASSIGNED

People

(Reporter: p.j.lechowicz, Assigned: ndo84bw)

References

(Blocks 4 open bugs)

Details

Attachments

(1 file)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.106 Safari/537.36

Steps to reproduce:

  1. There are two personal calendars on sabre calDAV server (Nextcloud calendar server based on sabre.io)
  2. One person invites the second one
  3. The invited person accepts invitation right after receiving it.

Actual results:

You get:
"Processing message failed. Status: 80004005."
The invitation message is not processed.

(Note this important observation: this happens only if calendar is not synced after receiving invitation. If you manually sync calendar (after receiving invitation!), accepting works).

Expected results:

The invitation message should have been processed without failure.

There's a thread on Nextcloud's github about this issue. Here's the link to my comment in which I make an assumption this is TB's fault: https://github.com/nextcloud/server/issues/17915#issuecomment-733774681

I've done some indepth testing, and here's what I've found:
After some debugging in console I found that the reason of this behaviour is that when person 1 sends an invitation to person 2, the latter one receives ics file with it's original name. Meanwhile, on sabre server the file name is being changed, and then server does not allow changes untill Thunderbird client gets notified of an item with changed name, which happens on sync.
The possible solution (maybe best) is to force sync calendars before processing data for iTip accept button action. This can be done when opening an email with a new ics file.

Component: Provider: CalDAV → E-mail based Scheduling (iTIP/iMIP)

Note this important observation: this happens only if calendar is
not synced after receiving invitation. If you manually sync calendar
(after receiving invitation!), accepting works

I think Thunderbird should perform a sync of the target calendar before trying to make changes to it. This way it would recognize that the appointment already exists and only needs to be updated.

This synchronization problem is really annoying. In the NPO where I work, we receive several support tickets every week from our employees reporting this error. It would be great if it could be fixed.

Confirm, quite annoying and we get lots of reports on that. Workarounds used till now (manual sync or 1 minute refresh interval). So we would be very happy to see this solved.

Same issue with the new version 91.9.0. Workaround still works but we cannot expect people to use that in their daily work. It would be great if this problem would be fixed.

Seing this with version 91.10.0, webex invite from other user on same Exchange mail/calendar server; manual sync overcomes it.

I'm still seeing this in v106Beta4

Hello, thank you so much for your work on Thunderbird. I'm just surprised that there's no answer at all from the Thunderbird team: I would fully understand if it's not a priority, but this is an issue met by so many people, a lot of them have investigated and proposed solutions (see https://github.com/nextcloud/server/issues/17915#issuecomment-733774681): would it be possible to have at least a comment?

Let's me at least mark it NEW.

Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Accepting invitation before calendar sync fails (Status 80004005) → Accepting invitation before calendar sync fails (Status 80004005) - Thunderbird should perform a sync of the target calendar before trying to make changes to it.

Thank you Magnus :)

I have also noted something: this issue happens in the following case:

  1. Receive an invitation
  2. Accept it > it is in the calendar
  3. Delete the event
  4. Receive an update of the invitation
  5. Accept it β†’ this triggers the error

Issue is still present: Thunderbird 102.11.0 (64bit), Nextcloud 26.0.1, Windows 10 (64bit).
It is sad that this problem is not prioritised, as it is one of the fundamental functions for collaborative working.

Issue is still present: Thunderbird 102.11.0 (64bit), Nextcloud 26.0.1, Windows 10 (64bit).

Error console output:

CalDAV: Unexpected status adding item to <calender name>: 412
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;BYMONTH=3;BYDAY=-1SU
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
TZNAME:CET
DTSTART:19701025T030000
RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
CREATED:20230511T092721Z
LAST-MODIFIED:20230511T092843Z
DTSTAMP:20230511T092843Z
UID:c51d7db8-4e80-4d10-85af-0df4f967006e
SUMMARY:TEST VE
ORGANIZER;PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICIPANT;SCHEDULE-AGENT=CLIENT:
mailto:<organizer mail>
ATTENDEE;RSVP=TRUE;PARTSTAT=ACCEPTED;ROLE=REQ-PARTICIPANT:mailto:<invited person mail>
DTSTART;TZID=Europe/Berlin:20230511T183000
DTEND;TZID=Europe/Berlin:20230511T193000
TRANSP:OPAQUE
LOCATION:<dummy>
X-MOZ-INVITED-ATTENDEE:mailto:<invited person mail>
X-MOZ-RECEIVED-SEQUENCE:0
X-MOZ-RECEIVED-DTSTAMP:20230511T092740Z
END:VEVENT
END:VCALENDAR

Assert failed: error on iTIP processing
calUtils.jsm:109
ASSERT resource:///modules/calendar/calUtils.jsm:109
onOperationComplete resource:///modules/calendar/utils/calItipUtils.jsm:1284
action resource:///modules/calendar/utils/calItipUtils.jsm:1880

I can confirm that this bug still exits in Thunderbird 128.3.2esr on Linux. I have multiple calendars synced, a few on Nextcloud 29.0.8 (work) and two on Nextcloud 30.0.1.

When i receive an invite and forget to "force sync" by dis- and enabling offline-support for the calendar, i get the error 80004005. The linked nextcloud issue mentions that the server throws the following error: /var/www/nextcloud/apps/dav/lib/CalDAV/CalDavBackend.php","Line":1264,"message":"Calendar object with uid already exists in this calendar collection."

Nextcloud will add the invite to the calendar as "tentative"/"unconfirmed". Thunderbird does not know that event by adding the mailed ICS to the Calendar there is a conflict. Someone on the Nextcloud issue has a nice writeup of the issue, see: st3iny debugging the issue with mitmproxy

Would it be possible to force a sync when one receives an invite? Since there is already the indicator that there are outstanding invites to process in the status bar, enabling that indicator might be a good time to sync.

Thanks,
Michael

Hi,
have the same issue.

Tunderbird version : 128.9.1
Networkcalender: calDAV based on SOGo (Version not known).

I noticed that it makes a difference if calender is set to offline support or not.
(Which there are other calDAV Lightning related bugs that have issus with the offline support like https://bugzilla.mozilla.org/show_bug.cgi?id=1694709)
offline support: 80004005 like reported
no offline support I get another error message: Status-Code: 2147500037, Server replied with http412, Error MODIFICATION_FAILED.
Then after trying to add the invitation to the calender the calender is marked as not accessible (Triangle with !), while it worked before. Toggeling offline support fixes that again, but invite can't be added what so ever.

Interestinly I can add the invite to another calender on the exact same instance of SOGo, but it is not the one the appointment is ment to be in.

Thanks,
Jonas

Confirming this issue on Thunderbird 140.3.0esr (64-bit), Fedora 43, with Nextcloud 31.0.10 as back-end calendar server. Nextcloud Calendar 5.5.7.

Hello everyone,
this issue is still very much an issue. It also looks like nextcloud will not add a workaround for thunderbirds behaviour, see this recent comment on a PR for nextcloud: https://github.com/nextcloud/server/pull/61207#issuecomment-4801836693

Is this, by any chance, fixed by the planned changes to the calendar ui? Having good groupware integration would be especially nice for al those orgs that are trying to depend less on microsoft/google/... and have thunderbird as the outlook desktop replacement (with nextcloud as their backend).

Either way, thanks everyone for your work on thunderbird and have a nice day,
Michael

When an invitation comes from an organizer on the same CalDAV server as the
invitee, the server already holds the event. It deposits a copy into the
invitee's calendar (under its own object URI) when the invitation is sent, so
if the user accepts before Thunderbird has synced that copy, the client still
treats the event as new and sends it as a create ("If-None-Match: *"). The
server rejects the duplicate UID and the acceptance is lost: Nextcloud returns
a bare HTTP 400; conformant servers return 409, optionally with the
CALDAV:no-uid-conflict precondition defined in RFC 4791 section 5.3.2.

Recognize this collision and recover from it instead of surfacing an error:

  • CalDavCalendar.doAdoptItem classifies the failure (a 409 Conflict, a
    CALDAV:no-uid-conflict element on any 4xx response, or Nextcloud's bare 400)
    and reports the new calIErrors.DAV_UID_CONFLICT, recording the conflicting
    resource's href when the server provides one.
  • For a live accept, ItipItemFinder.resolveUidCollision fetches the existing
    resource (by href, or via a full refresh) and applies the participation
    status to it with modifyItem, which also replies to the organizer.
  • For an accept made while offline,
    CalCachedCalendar.reconcileOfflineCreateConflict does the same during
    playback, applying the captured response to the server's copy so the next
    sync no longer silently overwrites it.

Add xpcshell coverage for the detection (Nextcloud, Radicale and SOGo response
shapes) and for both the live and offline recovery paths.

Assignee: nobody → ndo84bw
Status: NEW → ASSIGNED
Attachment #9602823 - Attachment description: Bug 1717401 - Resolve CalDAV UID collisions when accepting an invitation before sync. r=darktrojan → Bug 1717401 - Resolve CalDAV UID conflicts when accepting an invitation before sync. r=darktrojan
See Also: → 1850108
Blocks: 2061849
Blocks: 2061859
Blocks: 2061861
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: