Delete of exception rows (`RECURID IS NOT NULL`) silently no-ops

[rfc2822]

Overview

When a sync adapter calls delete that targets exception rows
(RECURID IS NOT NULL), SyncContentProvider silently excludes those rows by appending
AND RECURID IS NULL to the WHERE clause. The provider returns 0 and throws no error.

Related code:

jtxBoard/app/src/main/java/at/techbee/jtx/SyncContentProvider.kt

Line 197 in 65ff0e4

CODE_ICALOBJECTS_DIR -> queryString += "$TABLE_NAME_ICALOBJECT WHERE $COLUMN_ID IN ($subquery) AND $COLUMN_RECURID IS NULL " // recur instances must never be deleted by SyncContentProvider in bulk

Steps to reproduce

// Precondition: at least one exception row with the given UID exists in the database

// we explicitly want to delete all exceptions
val rowsDeleted = client.delete(
    collectionUri,
    "${JtxContract.JtxICalObject.UID}=? AND ${JtxContract.JtxICalObject.RECURID} IS NOT NULL",
    arrayOf(uid)
)
// rowsDeleted == 0, exception rows NOT deleted, no exception thrown

Result

Actual: returns 0, exception rows remain, no error.

Expected: rows deleted, or an exception so the caller knows the operation was refused.

ContentProvider.delete() returning 0 normally means "nothing matched" — a sync adapter cannot
distinguish this from "rows were silently excluded".

[patrickunterwegs]

Hi, what use case makes you want to delete all exceptions?
So far this logic was a jtx Board internal logic where recurring entries are recreated based on the information on the main entry and the additionally delivered entries with the same UID as well as the exceptions in the EXDATE. If you start deleting recurring entries the logic in jtx Board might behave in an unexpected way.

Or do you just mean technically jtx Board should throw an exception when you try to delete an entry by its UID with a RECURID?

[rfc2822]

Hi, what use case makes you want to delete all exceptions?

In CalDAV, we download an .ics that contains the main event + all exceptions. To update such an event plus exceptions, DAVx5 usually

1. deletes the exceptions because they may become invalid when the main row is updated (imagine that the main event is moved from 12:00 to 13:00 – then all recur-ids at 12:00 will become invalid → undefined behavior and the idea was to avoid any situation with undefined behavior),
2. updates the main row according to the downloaded iCalendar,
3. adds the new exceptions from the downloaded iCalendar again.

Or do you just mean technically jtx Board should throw an exception when you try to delete an entry by its UID with a RECURID?

Yes, if jtx Board really wants that restriction, it would be good to have it documented in the contract and to throw an Exception in the case that is not supported.