All Production RecordSaves rejected (BAD_REQUEST, _pcs_data) for every user of my container; Development works — FB24378074

App & System Services iCloud
BusProtection OP
Created 1d
Replies 2
Boosts 0
Views 50
Participants 2

My SwiftData app (NSPersistentCloudKitContainer mirroring, private database only) cannot save any record to its CloudKit Production environment, for any user. Development works flawlessly for the same devices, accounts, and code.

Signature, from CloudKit Console Production logs: every RecordSave to zone com.apple.coredata.cloudkit.zone fails with overallStatus USER_ERROR, error BAD_REQUEST, returnedRecordTypes "_pcs_data". Reads and zone setup succeed in the same sessions (ZoneSave, SubscriptionCreate, DatabaseChanges, ZoneChanges). Zero successful RecordSaves have ever occurred in this container's Production environment.

Facts established so far:

  • 4 of 4 users fail identically (my account + 3 TestFlight testers on unrelated iCloud accounts, iPhone and iPad, iOS 26.6/26.6.x) — so this is not one account's Advanced Data Protection key state.
  • Schema was deployed Dev to Production via Console; the Deploy sheet now reports zero pending changes, and Export Schema from BOTH environments yields identical record type sets. _pcs_data appears in neither export — it is a server-managed system type, so there is no developer action (Console or cktool) that can add it to Production.
  • The model declares no encrypted attributes (allowsCloudEncryption appears nowhere).
  • Entitlements verified with codesign on the shipped TestFlight binary: icloud-container-identifiers, icloud-services=CloudKit, production environment — all correct.
  • Client-side the failure is silent: CKAccountStatus is .available, the container initializes, no error surfaces; the mirroring delegate just stops exporting.
  • Tried without effect: reboots, reinstalls, force-quits, per-app iCloud toggles; storage has ample headroom.

This matches the signature in thread 838743 (FB23731287, FB24150787), where multiple developers report the same behavior, unresolved.

Filed as FB24378074, which now carries: a CloudKit-profile sysdiagnose captured during a timestamped reproduction, the matching server-side requestId/operationId for that exact save (9265D1CA-86BF-4CEB-A432-43F3F39C891E / A2A2B0F98B389DF8), schema exports from both environments, and a full fault-elimination audit.

Question for DTS: what makes a Production environment reject _pcs_data record saves that Development accepts, and what is the supported path to repair this container's Production PCS handling? A live TestFlight beta (a family app; device-to-device sync fully down for all users) is waiting on this. Happy to run further diagnostics on request — a minimal repro project against a fresh container is prepared.

Case-ID: 21696635

Answered by DTS Engineer in 902338022

I recently saw exactly the same error in the other case. The conclusion of my investigation on the case is:

  • The error message ("_pcs_data") is actually a red herring.
  • The real culprit is that the CloudKit schema does not completely match.

Given that the symptom is the same, the first thing I’d check is if your production schema completely matches your Core Data model. To do so, use CloudKit Console to ensure that each Core Data entity and attribute has a CloudKit counterpart. See the following article for the mapping rules:

The sysdiagnose provided in FB24378074 seems to confirm this diagnose as well – From there, I see the following error, which indicates that "field 'CD_createdAt' in record 'CD_AdultSeason'" does not exist in your production schema:

Operation A2A2B0F98B389DF8 finished with error: <CKUnderlyingError 0x14d690d50: "PartialFailure" (1011); "Failed to modify some records"; partial errors: { 0CFF0EA9-077E-46BF-A190-EE2388137B06:(com.apple.coredata.cloudkit.zone:defaultOwner) = <CKError 0x14e876820: "Invalid Arguments" (12/2006); server message = "Cannot create or modify field 'CD_createdAt' in record 'CD_AdultSeason' in production schema"; op = A2A2B0F98B389DF8; uuid = 9265D1CA-86BF-4CEB-A432-43F3F39C891E> ... 32 "Batch Request Failed" CKErrors omitted ... }><CKError 0x14c283900: "Partial Failure" (2/1011); "Failed to modify some records"; uuid = 9265D1CA-86BF-4CEB-A432-43F3F39C891E; container ID = "iCloud.Michael.Convention-Companion"; partial errors: { 0CFF0EA9-077E-46BF-A190-EE2388137B06:(com.apple.coredata.cloudkit.zone:defaultOwner) = <CKError 0x14e876820: "Invalid Arguments" (12/2006); server message = "Cannot create or modify field 'CD_createdAt' in record 'CD_AdultSeason' in production schema"; op = A2A2B0F98B389DF8; uuid = 9265D1CA-86BF-4CEB-A432-43F3F39C891E> ... 32 "Batch Request Failed" CKErrors omitted ... }>

This error is explicitly called out in the following technote section:

You can look into your sysdiagnose to see the error as well. How to do so is detailed in the following technote section:

I know you've confirmed that "the Deploy sheet now reports zero pending changes," but it can be that at the moment you deployed your schema, the development schema had the schema mismatch issue as well, or that CloudKit Console fails to detect the difference, which may happen in some corner cases.

Best,
——
Ziqiao Chen
 Worldwide Developer Relations.

Replies  2
Boosts  0
Views  50
Participants  2
DTS Engineer OP
Apple
1d
Accepted Answer
Recommended

I recently saw exactly the same error in the other case. The conclusion of my investigation on the case is:

  • The error message ("_pcs_data") is actually a red herring.
  • The real culprit is that the CloudKit schema does not completely match.

Given that the symptom is the same, the first thing I’d check is if your production schema completely matches your Core Data model. To do so, use CloudKit Console to ensure that each Core Data entity and attribute has a CloudKit counterpart. See the following article for the mapping rules:

The sysdiagnose provided in FB24378074 seems to confirm this diagnose as well – From there, I see the following error, which indicates that "field 'CD_createdAt' in record 'CD_AdultSeason'" does not exist in your production schema:

Operation A2A2B0F98B389DF8 finished with error: <CKUnderlyingError 0x14d690d50: "PartialFailure" (1011); "Failed to modify some records"; partial errors: { 0CFF0EA9-077E-46BF-A190-EE2388137B06:(com.apple.coredata.cloudkit.zone:defaultOwner) = <CKError 0x14e876820: "Invalid Arguments" (12/2006); server message = "Cannot create or modify field 'CD_createdAt' in record 'CD_AdultSeason' in production schema"; op = A2A2B0F98B389DF8; uuid = 9265D1CA-86BF-4CEB-A432-43F3F39C891E> ... 32 "Batch Request Failed" CKErrors omitted ... }><CKError 0x14c283900: "Partial Failure" (2/1011); "Failed to modify some records"; uuid = 9265D1CA-86BF-4CEB-A432-43F3F39C891E; container ID = "iCloud.Michael.Convention-Companion"; partial errors: { 0CFF0EA9-077E-46BF-A190-EE2388137B06:(com.apple.coredata.cloudkit.zone:defaultOwner) = <CKError 0x14e876820: "Invalid Arguments" (12/2006); server message = "Cannot create or modify field 'CD_createdAt' in record 'CD_AdultSeason' in production schema"; op = A2A2B0F98B389DF8; uuid = 9265D1CA-86BF-4CEB-A432-43F3F39C891E> ... 32 "Batch Request Failed" CKErrors omitted ... }>

This error is explicitly called out in the following technote section:

You can look into your sysdiagnose to see the error as well. How to do so is detailed in the following technote section:

I know you've confirmed that "the Deploy sheet now reports zero pending changes," but it can be that at the moment you deployed your schema, the development schema had the schema mismatch issue as well, or that CloudKit Console fails to detect the difference, which may happen in some corner cases.

Best,
——
Ziqiao Chen
 Worldwide Developer Relations.
BusProtection OP
1h

Confirmed resolved — and thank you, this diagnosis was exactly right. Marking it accepted.

The missing field traces cleanly in my history: createdAt was added to that model four days before the schema was deployed to Production, and that deploy missed the field while the Deploy Schema Changes sheet reported zero pending changes (the corner case you described). A later deploy on Aug 19 — made to add two new record types for a feature — happened to carry the missing field: Production logs show the container's first successful RecordSave ever within hours of it, and normal two-way sync for all users since.

For anyone landing here with this signature: compare BOTH environments' schemas field by field, not just the record-type lists (mine matched perfectly at the type level), and verify a deploy with a live save plus a Production log check rather than trusting the deploy sheet. The real error never appears in the Console log entry — it only surfaced in a CloudKit-profile sysdiagnose, exactly as TN3163 describes.

Case-ID: 21696635 / FB24378074 — this resolves both.

All Production RecordSaves rejected (BAD_REQUEST, _pcs_data) for every user of my container; Development works — FB24378074
First post date Last post date
 
 
Q