I have a macOS app using NSPersistentCloudKitContainer with separate private and shared persistent stores and zone-wide CloudKit Sharing.
The same Core Data model and sharing implementation work correctly in Development: the complete object graph is shared and bidirectional owner/participant synchronization works.
In Production, however, sharing is stuck in a partially exported state.
The owner has a complete and internally consistent Core Data object graph. fetchShares(matching:) reports the expected managed objects as belonging to the Production share. However, inspection of the Production shared CloudKit zone shows that many of the corresponding CKRecords were never exported.
For example, the participant successfully imports records that actually exist in the shared zone, but entire expected record types such as CD_Missionary and CD_Area are absent from that zone.
The Production owner's private persistent store repeatedly reports failed setup/export events. The relevant Core Data + CloudKit log pattern is:
Never successfully initialized and cannot execute request due to error: CKErrorDomain Code=2
with an underlying:
CKInternalErrorDomain Code=1011
I also correlated multiple failed Core Data export events with CloudKit server logs. Within seconds of the failed exports, CloudKit reports:
Database: PRIVATE Operation: RecordDelete Overall Status: USER_ERROR Error: BAD_REQUEST Returned Record Type: _pcs_data
The failure is reproducible across multiple export attempts.
The Production shared zone itself exists and has zone-wide sharing enabled. The expected cloudkit.share record type is present in Production. I compared the visible Production and Development schemas, including cloudkit.share, and found no obvious record-type/field discrepancy.
The important comparison is that Development sharing with the same model/implementation works correctly, while the existing Production mirroring/share state repeatedly fails.
I have filed Feedback Assistant report FB24739413, including a sysdiagnose captured while the failure was active, Core Data/CloudKit event diagnostics, CloudKit server-log request IDs, store identifiers, zone information, and reproduction details.
My main question is about recovery rather than diagnosis:
What is the supported way to recover an existing Production NSPersistentCloudKitContainer share/mirroring state like this and cause the missing managed objects to be exported, without deleting or purging the owner's managed objects?
I have deliberately not reset the Production environment, deleted/recreated the share, purged the shared zone, reset the owner's persistent store, or mass-modified the managed objects to try to force re-export.
In particular, I understand that purgeObjectsAndRecordsInZone can delete the corresponding managed objects, so I do not want to use destructive recovery techniques without guidance.
Is there a supported mechanism for rebuilding/reinitializing the Production mirroring/share state while preserving the owner's existing Core Data object graph, or is this a situation that requires intervention/instructions from Apple?
Environment
macOS 26.6.2 Core Data + NSPersistentCloudKitContainer CloudKit private + shared persistent stores zone-wide sharing Production failure only Development sharing works correctly Feedback: FB24739413