502014 - a server-side failure won't disable the calendar

Status: NEW

(Calendar :: Provider: CalDAV, defect)

Description

[Wolfgang Sourdeau]

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; fr; rv:1.9.0.11) Gecko/2009061317 Iceweasel/3.0.11 (Debian-3.0.11-1)
Build Identifier: 20090626030645

This works for return codes 404, but not for others, such as 502... A patch will be attached.

Reproducible: Always

Comment 1

[Wolfgang Sourdeau]

Attachment: fix for the mentionned problem

This code add error handling for all error codes > 399. Also, it initially marks caldav calendars as disabled so that all operations will be prevented at launch until the calendar is properly refreshed. In normal times, this is not needed but it MAY happen that the connection is silently dropped, thereby preventing any results until a timeout occurs.

Comment 2

[Philipp Kewisch [:Fallen][☁️📆]]

Comment on attachment 386556 [details] [diff] [review]
fix for the mentionned problem

I'm a bit skeptical that disabling the calendar and marking it readOnly at creation is a good idea. If I create a new uncached calendar, how is the calendar enabled? Won't it show up as readonly (lock icon) and disabled (grayed out) after it was created?

I assume that reenable will enable the calendar, but this seems to be a patch that is not checked in on hg tip yet? Even if so, I don't think we should use the disable logic to keep requests from happening. The logic makes sense for users disabling the calendar manually or if login fails. If we keep the calendar disabled until it refreshes, what keeps the user from just enabling it manually?

Please clarify and then attach a new patch, preferably one that applies directly to hg tip.

Comment 3

[Philipp Kewisch [:Fallen][☁️📆]]

Wolfgang, any updates here?