NSPersistentCloudKitContainer export blocked account-wide by failing _pcs_data RecordDelete (BAD_REQUEST)

Question

Created 3w

Replies 2

Boosts 0

Participants 2

Since ~July 10, NSPersistentCloudKitContainer export has failed on every device on my iCloud account; import still works. In CloudKit Console → Logs (Production), the only failing operations are RecordDelete/RecordSave of record type pcs_data (error BAD_REQUEST) in the private com.apple.coredata.cloudkit.zone. No CD* app-record failures; the app schema is fully deployed to Production.

Advanced Data Protection is enabled on the account, so PCS keys are managed end-to-end on-device. This looks like a wedged PCS key state rather than an app/schema problem.

Tried with no effect: toggling ADP off/on, toggling iCloud Keychain, multiple reboots, app reinstall, extended foreground on Wi-Fi. Still failing after updating from iOS 27 Seed 3 to beta 4.

Is there a way to get the account's Protected Cloud Storage key state reset so export can resume? Happy to share the Feedback number and sysdiagnoses privately with an Apple engineer.

Answer 1

NavismareYachtLogistic OP

1w

Same issue here, filed as FB24150787. Two iOS devices (iPad Air 5th gen, iPhone 17 Pro, both 26.5.2), ADP enabled: every export fails with RecordSave → BAD_REQUEST, returnedRecordTypes _pcs_data, in com.apple.coredata.cloudkit.zone. Import still works. Device reboots and toggling the app's iCloud switch do not help. Interesting data point: the same app/account on a Mac whose sync state was set up fresh after the wedge exports fine — and CloudKit Console shows an unrelated user of our app with the exact same failure signature. So this looks account/PCS-side, not app-side. The device-side PCS identity is valid per pcsstatus.txt, pointing to a server-side inconsistency in the zone's _pcs_data manifest.

Answer 2

fine441 OP

4d

Thank you, this is really helpful confirmation. I have the same signature on my side, filed as FB23731287 (13 July). Two devices, iPhone and iPad, single iCloud account, Advanced Data Protection on, both on iOS 27 betas. Only failing operations are pcs_data in com.apple.coredata.cloudkit.zone returning BAD_REQUEST. CD record saves are not rejected, import still works, and the schema is fully deployed to Production. A single failed _pcs_data op fails the whole export event and disables the mirroring delegate for the rest of the session.

Your fresh-Mac data point is the most useful thing I have seen on this. It lines up with what I am seeing: reinstalling the app on the already-affected devices does not clear it, which fits the idea that a reinstall on the same OS and account re-derives the same PCS material rather than provisioning genuinely fresh. A device that has never joined the account before gets clean PCS state and exports fine to the same zone. That points squarely at a device-side PCS provisioning wedge against a zone that is otherwise healthy, not app or schema data.

So we now have at least two developers (FB23731287 and FB24150787), plus the unrelated user you can see in your own Console, with an identical signature. That feels like a CloudKit-side regression rather than anything either of us can fix from the app.

For anyone from Apple reading: happy to provide sysdiagnoses, device Console captures of NSCloudKitMirroringDelegate, and CloudKit Console log excerpts. The ask is a way to reset or re-provision the account and zone PCS key state so export can resume, since no device-side or code-side step clears it.