SwiftData with CloudKit Error: Error updating background task request

• Just to be clear this is not a background task I have initiated. This is something done internally by SwiftData.
• That is the reason I would like to know the background task id.
• If I don't then the whole background processing would be blocked and defeats the purpose of the SwiftData background processing.
• This doesn't seem to be documented anywhere.
• Even if there is a way to debug this please let me know as symbolic breakpoints that I tried don't seem to work.

Any help on this would be greatly appreciated.

Thanks for the post. I have more questions than answers unfortunately. Other developers will jump into the thread with better answers.

Under the hood, SwiftData uses Core Data's NSPersistentCloudKitContainer to manage CloudKit synchronization.

It does not actually block SwiftData's CloudKit sync, and you should not attempt to add the internal identifiers to your Info.plist. Can you check if all the data get synced successfully?

I believe CloudKit synchronization relies primarily on built in push notifications, not BGTaskScheduler.

It’s interesting to me you get that message, I do not think is related to iCloud. I would like to get to the bottom of that issue, just by checking if any SwiftData is not synced.

Can you tell me if there is any issue with the data?

Albert
  Worldwide Developer Relations.

@DTS Engineer Albert, thanks for the response.

Error

• Please see the screenshot of the fault log,
• Subsystem for the log iscom.apple.cloudkit
• Category for the log is Scheduler

Answer to your questions:

• Cloud sync works and data gets synced, no issue with the data.
• Yes correct primary sync doesn't happen via BGTaskScheduler.
• However SwiftData / CloudKit initiates a background task to do some processing.
• The background is the one that gets blocked.
• This is a clean new project (no 3rd party libraries) and I have written the code so I am sure of that there is no background task I am initiating.

Testing / Sample project:

• If you really want to test it, please refer to the project attached in FB22634797
• Though FB22634797 is for a different issue, the Xcode project would throw the fault log in Xcode.
• It is a very simple project.

Question

• It would be great if someone from SwiftData / CoreData / CloudKit team can confirm this.

Oh I see, you created a bug 3 days ago about this. Looks like is in the correct team, so better for them to reply to your questions using the Feedback Assistant.

For more details on when you'll see updates to your report, please see What to expect after submission.

Albert
  Worldwide Developer Relations.

@DTS Engineer,

• That feedback is for a different issue.
• Should I create a separate feedback for this task id issue?
• I was suggesting that project for you to download and test on real device to reproduce the error.
• If you think you want me to create a separate feedback let me know.
• I already have a TSI opened and waiting for their response on it. Just got only an automated message.
• Is there a timeframe for someone to respond to TSI?

@newwbee thanks for the post, providing answers to your questions:

• In my opinion is not the best approach to provide a bug ID on a separate issue within the same project that is displaying the same issue.
• No.
• Simple focused projects should be minimal code to demo only the issue in hand.
• You have a TSI a bug and a forum post? Let's avoid redundancy and I would recommend to provide on the TSI a focused sample project only showing the issue discussed here.
• No. I would recommend for you to wait on the TSI.

Albert
  Worldwide Developer Relations.

Thanks for your responses.

FWIW, I've built out my own sync solution between CoreData and CloudKit, and it took some considerable forethought to support background uploads and downloads of binary data, separate from syncing CKRecord changes over time.

CloudCore manages its own CKFetch and CKModify operations like so…

func longLivedConfiguration(qos: QualityOfService) -> CKOperation.Configuration {
        let configuration = CKOperation.Configuration()
        configuration.container = container
        configuration.isLongLived = true
        configuration.qualityOfService = qos
        
        return configuration
    }

record["asset"] = CKAsset(fileURL: cacheable.url)

uploadOp = CKModifyRecordsOperation(recordsToSave: [record]…)
uploadOp.configuration = self.longLivedConfiguration(qos: .utility)
uploadOp.savePolicy = .changedKeys

It would be great to know if/when NSCloudKitContainer handles something like this.

@DTS Engineer Albert,

If it is not a lot of trouble would it be possible to check with the SwiftData / CoreData / CloudKit regarding the following:

• What is the background task ID for the background task? (so that the app can allow it and not block it)

It would be greatly helpful to know this because this is done by the framework and by blocking it we might lose some functionality that Apple had intended to provide.

Thanks!

@newwbee Can you provide a focused sample project where I can reproduce the issue on my machine?

If so, please share a link to your test project. That'll help us better understand what's going on. If you're not familiar with preparing a test project, take a look at Creating a test project.

Albert
  Worldwide Developer Relations.

Thanks @DTS Engineer

• I have created a feedback FB22670187
• It contains a sample project and also attached a video
• Run it on a real device
• The video shows the log being generated on Xcode.
• Look at the subsystem of the log, it is from com.apple.cloudkit
• It contains details about the fault and how to reproduce it.

@newwbee I don't think this is a bug until we can confirmed. I would recommend you to post the project in this forums instead of sending it to the team as a bug.

Creating a test project.

Albert
  Worldwide Developer Relations.

@DTS Engineer

• I am sorry this is an CloudKit project with entitlements, I don't want to post it in a public forum.
• You can download it from the Feedback FB22670187.
• Considerable effort has gone in creating a sample project, so I hope this is being investigated.
• Regarding the bug, I genuinely think it is a bug, if the team thinks otherwise, please reply to the feedback.

@DTS Engineer

Please refer to feedback FB22670054 instead, thanks!

@newwbee Thanks I would recommend to avoid sending duplicates bugs as there is an imposed overhead to manage those. The last one got routed to the correct team and they'll be happy to communicate with you.

For more details on when you'll see updates to your report, please see What to expect after submission.

Albert
  Worldwide Developer Relations.