Getting a list of deleted CloudKit records with an expired change token

The deletion history is maintained, you will receive the deleted records via the recordWithIDWasDeletedBlock callback.

Thanks, that's great to know!

Just to understand it better: it will usually return all deleted records since the last change token, but if I pass nil, then which deleted records will I get:

• all deleted records ever?
• all deleted records since device last received data?
• something else?

Just want to anticipate how many record ID's I should expect.

It seems that my colleague hasn't had time to follow up, and so I'd like to jump in to hopefully help.

When you fetch changes with previousServerChangeToken being nil, CloudKit returns deleted record IDs via recordWithIDWasDeletedBlock if:

• The deleted records were created on the device that is doing the fetch.
• The records was concurrently deleted during the fetching of changes.

This design choice is to make sure that apps can maintain the synchronization between their local cache, if any, and the server.

That being said, a device that is not the "creator" of any deleted records won't get any deleted record ID.

I hope this clarifies the behavior but please feel free to follow up if anything unclear.

Best,
——
Ziqiao Chen
 Worldwide Developer Relations.

Hi Ziqiao, thanks for the reply. Let me explain the situation I'm facing with my CloudKit-powered app.

1. Device A and B are both fully synced with the cloud.
2. On Device A, the user deletes a bunch of records and continues to use the app, letting the app sync in the background.
3. The user waits a few weeks before opening the app on Device B. When they open the app, it attempts to sync. The change token is expired, so it retrieves all of the records on the server.
4. My app is designed to treat this as if this is the user's first sync (a "unify" sync), so it compares all records on the server with all local records, then uploads any local records missing from the cloud and downloads any cloud records missing from the local database.
5. At this point, all of the items deleted in step 2 have been re-downloaded onto Device B.

Currently, my app never checks deletedRecordIDs on a unify sync. An easy fix would be to start processing this array even on unify syncs. But from your reply, it sounds like this will be an empty array on Device B because the deletions happened on Device A.

Is that true? If so, how can I resolve this problem? Unfortunately, it's somewhat common for my users to have a second device that they use very infrequently, and they get annoyed when previously deleted records re-appear on their second device.

To make my question more concrete, here's some CloudKit code demonstrating the scenario:

// device A
let newRecord = CKRecord(recordType: "Entry",
                         recordID: CKRecord.ID(recordName: "test"))
newRecord["name"] = "Length"
try await self.database.save(newRecord)
 
// device B
let (_, _, savedChangeToken, _) =
  try await self.database.recordZoneChanges(inZoneWith: self.zoneID, since: nil)
// successfully receives the Entry record with id "test" and saves locally
// we also persist savedChangeToken somewhere on device B
 
// device A
try await self.database.deleteRecord(withID: CKRecord.ID(recordName: "test"))
 
// several weeks pass
 
// device B (uses savedChangeToken from above, which has now expired)
let (_, deletions, _, _) =
  try await self.database.recordZoneChanges(inZoneWith: self.zoneID, since: savedChangeToken)
 
// is the following true or false?
deletions.map(\.recordID).contains(CKRecord.ID(recordName: "test"))

If it's false, how do I resolve the problem described above (deleted records re-appearing on the rarely-used device)?

1. At this point, all of the items deleted in step 2 have been re-downloaded onto Device B.

This doesn't sound right. I'd expect the following behavior:

a. If the deletion on device A (step 2) has already synchronized, the records would have been deleted from the server, and so would not be available for device B to download.

b. Otherwise, the records deleted on device A still exist on the server, and so would indeed be downloaded to device B, and yet, once the changes on device A is synchronized, device B should get the deleted record IDs when it fetches changes with a valid server change token (and hence remove records from the local cache). So the data will eventually synchronized.

c. If the changes on device A is synchronized concurrently while device B is fetching with nil token, device B should get the deleted record IDs as well (and hence remove the records), as mentioned in the second bullet in my previous post.

If you observe a different behavior, please share the details and I'd take a closer look from there.

But from your reply, it sounds like this will be an empty array on Device B because the deletions happened on Device A. Is that true?

No, that's not why I said. In your case, when you fetch changes with a nil server change token from device B, the result set should include the deleted record IDs for the records that were originally created on device B. It's about which device did the creation, not the deletion.

If it's false, how do I resolve the problem described above (deleted records re-appearing on the rarely-used device)?

As I described above, the deleted record should either not appear at all, or appear and then disappear after the changes on device A is synchronized. Again, I'll be super curious about what happens if you see otherwise.

Best,
——
Ziqiao Chen
 Worldwide Developer Relations.

Hi Ziqiao,

The important detail is step 3 - the user hasn't even opened Device B in weeks so that device is totally out of the loop. It's unaware of any deletions (or any changes at all) that have happened since step 1.

Everything was synchronized initially, but then the user starts deleting items on Device A, which get synced up to iCloud.

Meanwhile, back on device B, the app has been left unopened for weeks. When the user opens it up, they'll get .changeTokenExpired, and I'll fall back to the "unify" logic, the same behavior we use the first time this device syncs.

I'm really confused about how deleted record ID's work. For my use case, it doesn't matter which device the record was created on - any device that has had a long delay between fetches such that it needs to do a full fetch will need a list of everything that was deleted on the server since the last fetch.

For example, a user initially creates a record on Device A, syncs it to iCloud, Device B fetches. Later on, the user removes it on Device A and so my application code on Device A also removes the record from iCloud.

Device B, weeks later, fetches for the first time. It needs to know that the record has been deleted since its last fetch, regardless of the fact that, sometime far in the distant past, Device A had originally created it.

Does that make sense?

Thanks for the clarification. In the case where you fetch with nil change token, the server will give you all the records it has, which you can use to build up a new local cache (and destroy the existing one). Other than the bullet c in my previous post, you don't need to care about the deletion history, do you?

Best,
——
Ziqiao Chen
 Worldwide Developer Relations.

Sorry for the long delay in responding!

My implementation doesn't treat local data as just a local cache, or destroy any data on a fresh sync. CloudKit sync is totally optional in my app, so a user can turn it off or never use it, but would still want the data they see on their device preserved even if they do so.

So, when I get an expired change token, my app does a "unify" operation where it tries to match all the local records and the cloud records together. If there are cloud records that don't exist locally, it creates them locally; if there are local records that don't exist in the cloud, it creates them in the cloud.

The goal is to never, ever accidentally delete something and to give the user the ability to work without CloudKit. In essence, if there is no change token, it treats this like the first sync it's ever done with iCloud, where it needs to make sure that all data is merged into a single source of truth - rather than an incremental update where we are just making a few changes.

However, there's an issue with this approach: if the user has two devices fully in sync, then deletes items on one device, and waits a few weeks before syncing their second device, the second device will:

1. Get an expired change token.
2. Begin the merge process.
3. Create records in iCloud for all of the local records deleted on the first device (since they've been on the second device all along)

Unfortunately, step 3 would include any items that the user deleted on their first device: they were on both devices when everything was in sync, and because the second device never got the chance to run an incremental sync and pull in those deletions, it has no idea that the items should be gone.

I could easily resolve this problem if, on the second device, even with a change token of nil, CloudKit told me about every deletion that had happened since its last connection to the server. I could just go through that list and apply the deletions before running the merge algorithm. But if it only includes deletions made on the same device, my app doesn't have a way of knowing what the user has deleted since the last sync.

Hopefully that's a little clearer than my first explanation. Basically, I want to know if the original answer or the second answer in this thread is correct: does it include everything since the last communication with CloudKit, or only things deleted on the same device?

If the answer is the latter, I'm not really sure how to prevent deleted items from coming back like this.