Package: davical Version: 1.1.12-2.1 Severity: important Tags: patch upstream
Dear Maintainer, A CalDAV calendar-query REPORT whose <C:time-range> has a "start" but no "end" -- which per RFC 4791 s.9.9 means +infinity -- silently drops every event whose next occurrence falls more than 730 days after "start". Impact: this is silent data loss. Clients such as DAVx5 send exactly this query shape when configured to limit how far into the *past* they sync, so future events (and sparsely recurring ones) simply disappear from the device with no error. In my case a family member's event on a shared calendar was missing on Android while present on other devices. Reproduction (counting <href> results against a real collection): open (start only): 297 bounded (start + end=2999): 324 <- 27 events silently missing Cause: in inc/caldav-REPORT-calquery.php the post-fetch loop expands each resource into [expand_range_start, expand_range_end] and skips it when the expansion is empty (ComponentCount() == 0). For an open-ended range expand_range_end defaults to start + 730 days, so an event with no instance inside that cap is discarded even though the preceding getVCalendarRange()->overlaps($range_filter) test -- which treats a null upper bound as +infinity -- has already matched it. Regressed in 1.1.12 via upstream commit b40c96de, which extended the empty-expansion skip from explicit <C:expand> requests to every time-range query. Fix (one line): only enforce the empty-expansion skip when the upper bound is real (range_filter->until set) or the client explicitly requested expansion (need_expansion): - if ( $expanded->ComponentCount() == 0 ) continue; + if ( $expanded->ComponentCount() == 0 && ( $need_expansion || isset($range_filter->until) ) ) continue; Tested on Debian 13 (trixie) with davical 1.1.12-2.1: the open-ended query then returns the full set (324), the missing events reappear, and bounded / <C:expand> responses are byte-identical. The upstream regression test 0555-iPhone-REPORT (itself an open-ended query) confirms it. This also affects davical 1.1.13-2 in testing/unstable (same code). Forwarded upstream: https://gitlab.com/davical-project/davical/-/merge_requests/149 Given it is a one-line, targeted correctness fix with an existing regression test, I would like to suggest it as a candidate for a trixie stable point-release once merged upstream. Thanks for maintaining davical. Michael Braun
