I'm seeing "Request failed with http status code 503" CKErrorDomain 6

I’ve also found CloudKit troublesome, for me it was manifest errors even after I’d cleaned sync locations and restored databases from backup. I switched back to Legacy cloud and all is working fine as it was before, same databases. I’ve left a test database in CloudKit to see how it goes but for now my normal sync will be Legacy.

I’m also getting these manifest errors from CloudKit now it’s “working” again. The only fix seems to be to “clean” (delete) the DB in the CloudKit location. I’m not too worried about this since I’m using bonjour and iCloud(legacy) to sync as well so the data is in several places.

But my brief experience of legacy vs CloudKit syncing doesn’t encourage me to use CloudKit, but we do have plenty of choices here.

Ignore this for the moment if things are syncing as expected. The next maintenance release will have some garbage collection modifications that will likely quiet down these messages.

2 Likes

And @brianparker

As I just mentioned, if you’re seeing manifest errors but it’s syncing okay, you can ignore it fir now.

2 Likes

iCloud sync randomly stopped working for me yesterday (503) and I saw there was a new version of DTTG.

So this morning thought I’d give it a clean start:

  • Deleted DTTG from my phone
  • Installed new version
  • Synced data from iPad with Bonjour - perfect
  • Enabled legacy iCloud sync - perfect
  • Enabled CloudKit sync for 1 empty DB - spinning and eventually CKErrorDomain 6 (as on my iPad)

Apples services are reportedly up and healthy and other apps appear to be syncing via CloudKit (although with far less data).

Given that clearly other people are having a different experience I wonder if Apple blacklist specific apps on specific accounts if a usage threshold is reached, although I don’t know why I’m “special” (fast internet?).

I’m at a loss to explain it to be honest, but I do have 2 other working sync mechanisms so it’s more of an academic puzzle at the moment.

Well this morning using CloudKit is a very different experience. Clearly the API block has expired and I was able to clean the CloudKit sync store and upload again from scratch using the latest DTTG without any issues.

:crossed_fingers:

I was on the naughty step for 2 days this time!

It also seems considerably faster, although I can’t tell if that’s the new DTTG or because previously there had been a throttling issue with the Apple service.

It occurred to me that I always have “verify uploaded items” turned on, which must double the traffic. I wonder if this might be more likely to trigger throttling since (presumably) it hits the service twice as hard?

I would have assumed that was done via a checksum rather than a bit-for-bit comparison?

Interesting point. If the documents were uploaded to a proprietary service then the service could generate a checksum that could be compared with one generated client side.

Some of the sync stores are essentially dumb file buckets (like WebDAV) where the only way I can think that verification could work is to re-download and compare the fetched file.

But maybe Dropbox or iCloud have a feature like this. it does make sense for a file store designed for syncing and versioning.

1 Like

Interesting… I wonder how many people who have had the CK errors have this enabled (as it’s disabled by default). :thinking:

2 Likes

Yes, I did have it switched on when I was trying Cloudkit sync and receiving the manifest errors.

I never had this enabled, but also got the errors for my initial upload.

Good to know. Thanks!

The upload of manifests is actually always verified, independent of the setting to verify all uploaded contents.

Ok, yes thanks. I was only trying to give Jim some feedback on his earlier question regarding whether “verify uploaded items” was on when I was experiencing problems. I don’t have a problem of any sort now.

For info… I re-tested Cloudkit sync with the latest versions of DT and DTTG with no issue so I have switched my entire set of databases over - not one problem and sync is working fine and very fast too.

Glad to hear it! :slight_smile:

Same here I’ve had no issues for a while.

I’m still slightly suspicious that the chronic throttling issue was some apple service problem that they quietly resolved. At first it was working, then I was having trouble for days and suddenly it was fine again. And all with no action on my part and seemingly unrelated to the most recent DTTG update, since the problem persisted for a while after I updated. Still - all good now!

Reminds me of this, when Steve Jobs fired the head of the iCloud team :open_mouth:

1 Like

I‘m wondering if this problem is still „unsolved“ as I got so consistent CloudKit sync errors due to the rate limit that I had to completely shut-off the cloud sync and switch to my own WebDAV solely.
Other observation is that my 10 GB DB used 31 GB in icloud.

Are there any new workarounds?

Greetings

See here.

1 Like

Lots. The easiest one would be to use Bonjour sync. The general answer seems to be: Use anything but Apple’s cloud.