How can I find and remove what is creating CDMR sync request in Core Data/Cloud Kit App?

user_2196438 0
Viewed 344

My app uses Core Data and CloudKit together. I consistently get a debug messages like this:

020-12-16 11:05:48.933716-0600 Prayer Sparks[13035:4347318] [error] error: CoreData+CloudKit: 
-[PFCloudKitCKQueryBackedImportWorkItem queryOperationFinishedWithCursor:error:completion:](105):
 <PFCloudKitCKQueryBackedImportWorkItem: 0x2829375c0 - 
<NSCloudKitMirroringImportRequest: 0x281697ea0> 
ACD62C39-CCBB-4FDE-BBBE-337C9725E759> { CDMR:nil }: 
Failed due to querying for an unknown record type (not fatal, 
schema needs to be initialized): <CKError 0x28165c420: 
"Unknown Item" (11/2003); server message = "{
  "recordTypeId" : "CDMR",
  "title" : "did not find record type"
}"; uuid = EAF05A49-2FB4-460B-A93D-DBFD9FF1E755; container ID = "iCloud.com.stevenhovater.Prayer-Sparks">

A version of that debug message comes at even the lowest debug feedback levels, about every 5-15 seconds. My interpretation is that in the background, the app is queuing up a request to the public database to query for CDMR records (the way cloud kit approximates relationships in Core Data, as per the article here: https://developer.apple.com/documentation/coredata/mirroring_a_core_data_store_with_cloudkit/reading_cloudkit_records_for_core_data)

However, my app doesn't have any relationships in the model. It did at one point, but I've long since removed those. My suspicion is that somewhere the model generated something to manage the relationships in the background, and it's hanging around as an artifact somewhere. I've cleaned and rebuilt probably a hundred times since that relationship existed, and have deleted the "Derived Data" folder for the app multiple times as well. I've reset the schema in the CloudKit Dashboard and reinitialized it with dummy data several times as well, yet this message persists.

Any ideas where the culprit hides, and how to get rid of it?

cloudkit core-data
5 Answers

Had the same issue here. The messages have been appearing for a while now (ignored for as long as i could stand!) so I can't pinpoint exactly when the messages started appearing, but my best guess is that they started around the time that I moved my model to incorporate/merge private records with public records - something in the difference between the way NSManagedObject and CKRecords handle relationships perhaps?

Anyway - @Reinhard Männer's solution of creating an empty CMDR record in the CloudKit dashboard, and setting the indexes for createdTimestamp, modifiedTimestamp and recordName to queryable worked for me.

I did try creating dummy related entities in my data model, but it solve anything, I suspect because they were not being initialized/pushed to CloudKit in my situation, so the server knew nothing about them.

Instead, I gave up on all of that, cleared the decks and just manually added the empty CMDR record to my schema in the CloudKit dashboard, set the indexes to queryable, and voila! Did the trick - in the end, a 2 minute job.

user_168589640

I am having precisely the same problem. I have even gone so far as to start a new CloudKit Container to see if that would eliminate the error in the console. But it persisted. Just like you no relationships in the model.

Here is the console output for me:

2021-02-02 16:41:23.046546-0800 TheList[3209:705968] [error] error: CoreData+CloudKit: -PFCloudKitCKQueryBackedImportWorkItem queryOperationFinishedWithCursor:error:completion:: <PFCloudKitCKQueryBackedImportWorkItem: 0x280616440 - <NSCloudKitMirroringImportRequest: 0x283982c70> 473727C1-9A49-4CE0-A1A3-6971EA1D48AB> { CDMR:nil }: Failed due to querying for an unknown record type (not fatal, schema needs to be initialized): <CKError 0x28398e670: "Unknown Item" (11/2003); server message = "{ "recordTypeId" : "CDMR", "title" : "did not find record type" }"; uuid = 8C0327D8-066F-47A2-8FFF-41FD19C7D2C8; container ID = "iCloud.TheList">

user_44303820

I think I found a solution or at least a workaround. It seems to me that NSPersistentCloudKitContainer expects to have an M:N relationship in the model somewhere. To address that, I just created two empty entities and assigned them a connection to each other. Now the CloudKit dashboard contains a CDMDR Record type, and the error message is gone. This might be fixable by manually creating a CDMR record with the same attributes (see screenshot), but I haven't tried that yet. Model with two empty Entities CloudKit Dashboard with CDMR record type

user_17918840

Adding to @skahlert's answer, I added a pair of entities and a M:M relationship joining them, initialized the schema with them in place, and observed a CDMR record type appear in the dashboard. I then removed the pair of entities from my model and again initialized the schema to see if the CDMR record type was removed...it was not.

It would be handy if Apple automatically instantiated a CDMR when the public database is initialized. In the meantime, it appears we're simply adding a necessary piece for accessing the public database that otherwise has no effect on the individual app's function.

user_140347700

I had a m:m relation in my core data model, and the corresponding CDMR records on iCloud.
Then I changed the model so that it no longer had relations, and everything worked well.
Then I deleted the apparently no longer needed CDMR records in the iCloud dashboard.
Afterwards, my core data iCloud mirroring no longer worked with the log

<NSCloudKitMirroringImportRequest: 0x7b0c00099f60> 66A4A241-9DF2-4B4E-B50F-57E3C59BA12D> { CDMR:nil }: Failed due to querying for an unknown record type (not fatal, schema needs to be initialized): <CKError 0x7b0c0009c1b0: "Unknown Item" (11/2003); server message = "Did not find record type: CDMR";

Initializing the schema did not help. I also tried to add again a m:m relation, but the CDMR record was not created.

Next, I created an empty CDMR record in the dashboard, and added queryable indexes for createdBy, modTime, and recordID, and the mirroring worked again.

Eventually, I deleted the m:m relation, and the app kept working.

So it seems, that the only requirement is that any - even an empty - CDMR record with the necessary indexes exists.

user_19877260
Related