My feedback number which I also mentioned in a lab this year: FB13773922. I got the confirmation that the error should be reported theoretically, so it seems to be an issue in the OS.

@Aakif Are you seeing a spike in errors or a higher latency in your Telemetry data starting 20. March 2025? I have an increase in bandwidth and latency but cannot correlate the to any code changes I made during that time. As you posted this message also on the 20th, maybe it is related.

I see the same information in my logs. Could maybe someone provide information on this?

First, my feedback number: FB13329733. I took one of my DTS tickets and requested some help on this issue. This seems to be an actual bug in CoreData: Every Core Data CloudKit store has several tables to store the synchronization state, and ANSCKRECORDMETADATA is one of them. It stores the maps between Core Data entities and CloudKit record types, and has a unique constraint on its ZENTITYID and ZENTITYPK attributes. When migrating an existing store, Core Data analyzes the source and destination model versions, and updates the tables so they reflect the new model version. The constraint conflict, I reported, was triggered in the process. The issue doesn’t happen when I use NSPersistentContainer because Core Data doesn’t migrate the tables when CloudKit doesn’t get involved. The migration process is completely internal to Core Data, and there is no supported way for developers to impact the behavior. The DTS engineer couldn't provide me with more details except the notice that the issue has been forwarded to the CoreData team.

Did anyone have success with this? I'm currently facing the same issue in a project.

I see a similar issue on dragging a view around with the onDrag modifier: In the console I see lots of identical warnings: Found no UIEvent for backing event of type: 11; contextId: 0xcb35f894 When that happens my drag cancels and I have to retry it a couple of times before my drag works

I see the same issue and already submitted a feedback: FB12905731

For the cascade issue you can add deleteRule: in front of it. The issue regarding Variable 'self._$backingData' used before being initialized is something different. You are right, removing the default value fixes the compile time error but breaks automatic CloudKit sync (FB12905731).

I face the same issue. The app freezes and consumes all memory it has while being at 99% CPU.

I'm having the same issue with the same crash log. I filled a feedback with an example widget: FB12702894

I reached out to the Apple Developer Technical support and used one of my TSIs. I got a very nice reply explaining the error to me and I want to share my new learnings with everyone else here: “Cocoa-Error 134419” is an internal error indicating that the Core Data CloudKit aborts the persistent history analysis because the activity was deferred by the system. That normally happens when the system determines that Core Data CloudKit is using too many resources. From the app perspective, it means the app has too much data to export. Core Data CloudKit may continue the history analysis later and when the system allows, but before that, it can’t export data to CloudKit. From a developer's perspective, there is nothing you can do to prevent this (except not storing too much data in Core Data). "There is no way from the app side that can impact the resource balancing on the system side." I hope this helps everyone who is coming across this issue themself.

I have the same issue with my apps. My most used app only has an entry from a version that I release over 1.5 years ago. Is there any update regarding this issue? I can reproduce it in the latest Xcode 12, Xcode 13 beta and previous Xcode 12 and Xcode 11 versions.