There are hundreds of main records, each referencing hundreds of other entities' records, each referencing dozens of other entities' records- so no to a dump. Similarly, deleting a record associated with invalid/old keys has cascading effects - so no to that approach also. I fixed the problem using the approach described below.

I had assumed (hoped?) that resetting the development environment would clear any backlog of updates from the CloudKit sync, but this was not the case. The error still occurs and syncing stops once the reload from CoreData gets to the point where I'd made the faulty model changes. Reloading a correct schema into CloudKit doesn't work either. The update records must be persisting somewhere "behind the scenes" either in the Cloud or on my MacMini.

Unfortunately, the suggested approaches didn't fix the issue. As I said in the original post, I made some unwise changes to the model and a couple of relationships. I should have known, but was hurrying and not thinking clearly. This was some weeks ago and I'd parked the problem (was ill), so I can't remember what I did at the time. This also means that filing a feedback report would be inappropriate because I really can't be sure what I did, and with which versions of MacOS & Xcode.

Now requested developer support.

No, because this is a problem of my own making (i.e. an incorrect migration - worsened by an attempt to reverse the migration). I had thought of requesting developer support though: I think I still have entitlement for one.

Thanks for your reply Scott: you confirmed my perception. Most of my apps now are multi-platform (Mac, iPad, iPhone, Watch and sometimes TV) with CoreData/CloudKit storage and sync, so I use a common framework, fencing off functions that are not appropriate for a particular device. Only a couple of these apps might make it onto the AppStore, the rest for personal use, but I do need to think through the design implications before I get too far down the track. Regards, Michaela

Actually, now that I've had another look I'm beginning to doubt my solution: I can't remember the rules for context changes to objects modified by reference. Let me know if it doesn't work and I'll create a test app. Regards, Michaela

I've had a look at your linked post and I started preparing an answer for you, but I implement CoreData solutions differently and I'm not sure that my "quick fix" will actually solve your problem, without recreating you code here and testing - which I won't have time for at the moment. If you don't get an answer from someone else I might be able to look at it again over the weekend. Good luck and regards, Michaela

I have a busy morning here in Oz (currently 07:30), but I'll have a look at your code this afternoon - 6 or 7 hours from now. Regards, Michaela

I tried using FetchResultsController for Master and Detail records, but it was unreliable. This solution has CoreData manage the updates.

Yep, the switch sends an HTTP GET to the specified UR: tested by sending to one of my public websites with a dummy file name e.g. http://mywebsite.com/switchstate1.html - can see the request in the Apache access_log

Thanks Quinn. I'll have a look at SwiftNIO, although I'm not yet 100% sure what protocol the Switch uses. All I know is that for each Switch state I can provide a URL for it to contact (so assume it's HTTP): today I'll log it's IP address traffic in my firewall and see what's happening. There shouldn't be a port 80 conflict because the public WebServer is on a separate physical LAN, with all external (internet) incoming port 80 packets being directed to it by the Gateway. The switch and intended Listener are on the internal (private) LAN, which I can configure for port 80 between only their 2 IP addresses.

Thank you for your answer. I'm already using the Web Server built into MacOS for publicly facing web-sites, through the DMZ of my secure gateway to a different Mac. As I said, I don't need a full-blown web server and the Listener App's actions need to use Swift APIs, which are difficult to get to via Apache. I know the local IP addresses of the switch and listener. I've developed other Mac apps that constantly (well, every few seconds - but still always running) monitor blue-tooth devices and this is similar, except that the external device (switch) triggers the app's processing via an HTTP Post rather than Bluetooth connectivity with device update notifications. There will be a simple GUI (SwiftUI), for showing switch events, and events will be stored in CoreData and/or CloudKit (of which I've done many apps). The app will also send out alerts, the mode depending on the switch state reported. So, after further thought and reading, plus your answer, I'm inclined to build my own solution using Network Framework and URLSession - once I've gotten my ageing brain around the complexities. Hopefully I'll find some examples or tutorials to get an overview and options. Regards, Michaela

I'm happy to help out when able and available. I'll respond to these questions in another Answer, because the formatting in an Answer is easier to read than in a Comment. Cheers, Michaela.

Yes, that would do the job.