Long tasks must survive quit and reboot

What it is

Export, transcode, backup, a model download — often longer than one app session. A person swipes the app away, the OS kills background, the device reboots: the task must keep running or resume from a breakpoint, not start from zero, and not evaporate. What is durable is the task object: identity still there, the stretch already done still there, the remaining plan still there.

This leaf is lifetime across process and boot. Whether progress can be queried, whether completion notifies, is another surface. Without durability that surface is empty the next day — not a query failure, an object already dead.

Why it happens

The OS does not guarantee a foreground process lives through background. Mobile systems especially freeze or kill after minutes. A long task that lives only in that process’s memory has had its lifetime written as session lifetime. Durability writes the task description (what, how far, next) into storage outside the process, and hands execution to an executor the OS still honours: background transfer, a job scheduler, restore-on-boot logic. After reboot the executor wakes again, reads the description, continues from the breakpoint.

“Continue” and “resume” differ. Continue: the process is gone, the work still runs on the system side (a large upload handed to the system upload service). Resume: the work stopped too, but the breakpoint remains, and the next launch walks forward from it rather than redoing. Both beat evaporation; to the user the distinction has to be spoken: “still uploading” versus “will continue compressing when opened”. Saying it is still running when it is only a stored todo is a lie about lifetime.

Where it stops holding

Work that needs power and a network (upload) cannot continue through shutdown, only resume; do not still show “uploading” after shutdown. One-shot short work bound to the current screen (a filter preview) need not be durable. A secure wipe, sign-out, or uninstall should end unfinished long tasks with it, or durability becomes residue that cannot be removed. Another device on the same account does not inherit this device’s local transcode — the execution site is this hardware. When the OS refuses background work on low battery, the task should enter an explicit “waiting for charge”, not be treated as done or failed.

Applying it

• On submit of a long task, write description and breakpoint to durable storage at once. Do not wait for the first progress callback.
• Hand transfers that can go to a system executor to it. Those that cannot: on the next cold start, read the unfinished list and continue from the breakpoint.
• The first glance after reboot should show unfinished items, with honest state: “the system is still running this” versus “will continue when opened”.
• How to check: start an export or upload of at least two minutes, swipe the app away, wait for the process to die. Reopen: the task is still there, progress not from zero. Then again: start and immediately reboot. On boot into the product, the task should resume or show as resumable; the stretch already done should not be redone. If the list is empty after reboot, the object died.

Related

• Same group: I3.12.2 Concurrent background work needs priority, not first-come-first-served · I3.12.3 Submitted background work must be reorderable or cancellable · I3.12.4 Background resource use must be visible, or it looks like a leak
• Nearby: I3.07 Background tasks · I3.06 State persistence
• Search terms: durable job · resume after reboot · background transfer