I believe the expiration is happening from the progress not updating after ~30 seconds because there is no network (which my understanding is expected behavior, as the system can terminate the task when progress isn't updated) The part that is not expected is, after the task expires, based on the comment above, I should be able to avoid the failure UI notification by calling task.setCompleted(success: true). But no matter what I do, I always get the "Task Failed" failure notification (which seems to happen before the expirationHandler is even called). I'm ok that the task is expiring in this case, I would just like to avoid the failure notification and handle it myself

I've filed a bug/feature request on configurability of the failure notification, FB21601088 but to clarify, in response to If you don't want a task to be marked as "failed"... the solution is to "not" fail the task. Putting that another way, the "success" argument to "setTaskCompleted(success:)" is actually you telling the system what to do with the task you're completing, NOT communicating some higher level concept of what the task actually "did". My understanding is that if I do setTaskCompleted(success: true), then there would not be a failure notification even in cases where the system expires the task, but that is not what I'm seeing (by debugging, it seems the failure notification is already set before the expirationHandler is called, and it seems its immutable after that). Please let me know if I'm missing something and there is an easy way to surpress the failure notification in cases where the system expires the task.

Hi there, Following up on this, my interpretation of this response was that I could use setTaskCompleted(success: true) to avoid the UI notification of a task failure. But when simulating a situation where the system expires the task, I still see the UI failure even if I call bgTask.setCompleted(success: true) How can I avoid the UI notification in cases where the system kills the task?

Thank you! here is the bug number FB21338204

Here is the bug number FB21338185 The test file I am testing with is 7 GB, and on cellular the upload can be a bit slow. I can test again, but I think in case 1, the progress updater updates much more slowly than it does when directly updating the progress task in case 2. Perhaps the UI only looks at completedUnitCount and not fractionCompleted as well? If it's interesting I can see if I can try to repro it more clearly

I forgot to mention I am using multipart upload, and so completedUnitCount gets updated on each Chunk. I could reduce the chunkSize, but ideally would still prefer to just have it be kept alive by fractionCompleted (if that is indeed the issue)

Ah interesting, Based off that, it feels like I should NOT rely on the BGContinuedProcessingTask notifications (or whatever they are called) to communicate state. It seems like instead what I should do is do something like local notifications to communicate state and handle it more in my app, is that correct?

Update: I just tried replacing the child progress with a UrlSessionDelegate that updates the progress completedUnitCount directly, and it seems to be more stable (but I only tried this once) Potentially a bug with using Child Progresses to keep alive BGContinuedProcessingTasks?

Hi there, I posted about my task about uploading files here https://developer.apple.com/forums/thread/808756 and am also getting unpredictable expirations, especially on cellular connections. One thing I noticed is that when I tried to use the child progress, the fractionCompleted updates, but the completedUnitCount does not until the chunk is done. I wonder if expiration happens by looking at completedUnitCount and not fractionCompleted? If not, any other ideas as to why my UploadTask on cellular is getting killed much more frequently than on wifi? I fixed some issues on wifi where I noticed if the CPU usage is too high it gets killed, but I've since fixed those, and wifi is pretty stable, but cellular is very unstable.