The incremental path applied a page's removals before downloading its
changes, so a delete-and-recreate reported as removed one.ics + changed
two.ics purged the row before two.ics was ever fetched: the task came
back with sortOrder 0, no colour and no parent, and deletedLocally was
reported for a task nobody deleted. The same damage the sweep's
pre-download snapshot used to do, on the fast path. Bodies now go first,
after which the vacated href names nothing and the removal is the no-op
it should be — RFC 6578 reports each resource once, so a page cannot
both change and remove one href, and touched already guards what this
run wrote.
apply re-pointed a row's href in the hoisted index but left the old
entry naming those rows, so a later resource in the same batch read them
as displaced and deleted them: server holds two.ics with UID a (was at
one.ics) and one.ics now with UID b, and the rename is destroyed by the
resource that took its name. The in-memory twin of the same bug.
The download-side quarantine had no way back. At THRESHOLD the href is
stripped before the fetch, so apply — and with it succeeded — can never
run to clear the count, and a per-object ACL wrong for an afternoon hid
that task for the life of the install. The upload side is fine, since
stored and purge refund it there. The daily full reconciliation now
probes a quarantined href once: it costs one resource a day, and one
that answers clears its count.
makiolaj
ddcffa61b3