Calendar collections silently skipped in the harmonization loop

Harmonize advances collection sync cursor (hesn) without fetching entities.

Summary

During occ davc:harmonize <user>, a collection's sync cursor (oc_davc_collections.hesn) can advance while no corresponding entity rows are written to oc_davc_entities_calendars. At the same time no outbound sync-collection REPORT is issued to the backend for that collection at all. Because the cursor advances regardless, any events in the un-fetched delta fall permanently outside the range future incremental syncs will re-check. This appears to be the shared root cause beneath #94 (initial backfill) and steady-state incremental loss.

Observations

Under a single CLI davc:harmonize run with service debug enabled, task and contacts collections triggered concurrent PROPFIND/REPORT to the CalDAV backend, but one calendar collection (type = calendar) received no outbound request. It was absent from the loop's backend traffic, yet the harmonize returned exit 0 and the run reported clean.

Backend sync-token advanced correctly: a direct PROPFIND before/after a deliberate PUT confirms the backend (Radicale 3.7.4) advances its token on write and returns 403 valid-sync-token on an unrecognized token. The defect is on the consumer side.

Reproduction

Connect a service; confirm a valid hesn; make an external edit via any CalDAV client; run occ davc:harmonize <user>; observe hesn advances but no new row lands in oc_davc_entities_calendars, and (with backend access logging) no sync-collection REPORT is issued for the calendar collection URL while task/contacts URLs are queried.

Environment: Nextcloud 33.0.3; integration_davc 1.0.4; Radicale 3.7.4; MariaDB.

Impact

Incremental sync is unreliable for this version: because the cursor moves past un-fetched deltas. Incremental harmonize cannot recover them once the cursor has passed, and no error surfaces to user.

The only known recovery is a full resync (to my knowledge): invalidate hesn to force a full-compare fallback, per the #94 workaround. This is expensive to run routinely on multiple large collections for multiple users.

Related

• #94 - initial backfill never occurs
• #93 - a parser bug that can independently render fetched events invisible; compounding, not shared root cause

Start with the occ davc:harmonize <user> entry point and trace the collection loop, comparing the calendar path with the task and contacts paths that issue CalDAV requests. Reproduce with an external calendar edit and inspect oc_davc_collections.hesn alongside oc_davc_entities_calendars. Done means calendar collections issue sync-collection REPORT requests, write fetched rows, and do not advance the cursor past an unfetched delta.