Open Bug 2016998 Opened 3 months ago Updated 13 days ago

Recurring events broken with CalDAV in Thunderbird: sometimes single-instance edits delete the series or shift recurrence

Categories

(Calendar :: General, defect)

Thunderbird 140
defect

Tracking

(Not tracked)

UNCONFIRMED

People

(Reporter: schmitz, Unassigned)

References

Details

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:147.0) Gecko/20100101 Firefox/147.0

Steps to reproduce:

In Thunderbird, create a recurring event (e.g., weekly).

Pick one occurrence of the series.

Choose Edit only this occurrence (not the whole series).

Perform one of these actions:

    Cancel/delete only that occurrence, or

    Move the single occurrence to a different day/time, or

    Edit details for only that occurrence (title/location/etc.)

Let Thunderbird sync to Nextcloud via CalDAV.

Actual results:

Canceling/deleting a single occurrence sometimes makes the entire series disappear.

Moving/editing a single occurrence sometimes changes the recurrence rhythm of the series (RRULE behaves as if modified).

Sometimes the change shows up one week later than the week/occurrence that was edited.

Sometimes exceptions/changes appear twice (duplicates).

Expected results:

Only the selected occurrence is changed (proper exception via RECURRENCE-ID / EXDATE).

The rest of the series remains unchanged.

No duplicates, and the change applies to the correct date/week.
Component: Untriaged → General
Product: Thunderbird → Calendar
Summary: Recurring events broken with CalDAV in Thunderbird: single-instance edits delete the series or shift recurrence → Recurring events broken with CalDAV in Thunderbird: sometimes single-instance edits delete the series or shift recurrence

Could it be that iOS writes changes to shifted events in a recurring series differently than Thunderbird does? For example, if I reschedule or cancel a single occurrence in iOS, it may be stored with a different format or reference than Thunderbird expects.

As a result, when another update for the same series arrives later (e.g., another shifted or canceled occurrence), Thunderbird may not be able to match it to the correct event anymore—so you can’t properly respond to the invitation in Thunderbird.

I think I do have the Problems on events which were accepted with iOS oon earlier changes in the event series.

Just for info (might be related), there is another critical bug also related to recurring events with edit/exceptions: Bug 725276

Any new Information? We are using TB in enterprise environment and its very important to have that feature. I've also deleted the cache data, deleted the calendar integration and integrated the calendar as well. I stopped the connection with mobile Phone to focus on TB behavior.

I don't have access to a NextCloud calendar, but I can confirm using different server software that Thunderbird behaves as expected in this situation. So I suspect this is a NextCloud thing. Some server software will modify events that are sent to it. Other clients you have talking to the server could also be complicating things.

Here's what I would do to test:

  • Open the Thunderbird developer toolbox, and go to the network tab.
  • Follow your steps to reproduce the bug from comment 1.
  • Check that the PUT request to your server contains the changes you made.
  • Check whether the response to the REPORT request immediately after the PUT request matches what was sent.

Which different software server do you mean?

Well i think its a normal setup that you have the calendar on your phone as well (at least for reading...). Should working :(

My first test worked normal. PUT and Request did it great. But that was an event with no guests in it. I will test the same thing with an internal series. So i can check PUT and Request on both sides.

I used Radicale. Thunderbird doesn't change its behaviour based on the server it is talking to, so it did the same thing it would've done if it was talking to NextCloud.

Problems with editing one instance of a recurring event are not limited to NextCloud server. I can reproduce it with 365 Exchange server as reported on Bug 725276.

Just to clarify, Bug 725276 (that i reproduce here with 365 Exchange server) is related to read/visualization of the recurring series (the edit of a single ocurrence was previously made by other user on the Server, without Thunderbird). If you just read the calendar on Thunderbird, the recurring series in not shown correct compared to other Clients (Outlook, iPhone, etc...)

I deleted the recurring event (which was made in TB) and added a new recurring event.

I watched at PUT and REQUEST. Everything fine. After that i made two changes and also watched PUT/REQUEST. Everything fine.

Back to the other Client i accepted the recurring event, watched at PUT and REQUEST... everything fine. After that i accepted the two changes... everything fine but the deleted events were always different shown in mailwindow and i could press "delete" multiple times...

Two hours later the recurring event was suddenly broken.

I checked which client was connected at this time and it was TB. Could not looked at PUT and REQUEST cause the PC was in Homeoffice.

Any idea how i can get consistent reccuring event setup? my boss is angry and if we do not get it fixed, we will get back to exchange...

See Also: → 2000216

(Geoff won't be able to reply for week)

See Also: → 725276

Any new Ideas? Is getting worse and worse. Can not use this software in business setup with caldav under thoses circumstances. Still the same Problem: recurring event works until i make a change to one single event. After that the event series is broken on any client.

You need to log in before you can comment on or make changes to this bug.