Submitted background work must be reorderable or cancellable

What it is

The task is already submitted and a person’s priorities change: this image has to send first, that backup can go, a transcode tapped by mistake should stop now. Reorderable or cancellable lets already-submitted work still take a manual override, rather than, once handed over, only waiting for the executor’s own tempo. An unoverridable queue locks people in an expired plan.

This is not the same layer as cancel-during-wait: that is whether the current load can abort. This is the place and the life of background items that already exist as objects in a queue. A list-as-surface can live without manual sort; once there are several items and they run long, no override means the scheduler’s default cannot be corrected.

Why it happens

Submit is a reservation on future resource. After the reservation the world changes: a conversation gets more urgent, the wrong file was chosen, battery is critical. The executor does not know unless a person can change the reservation. Reorder changes relative order; cancel changes whether the reservation still exists. Both must hit real execution, not only the row order on a list: cancel must stop the running item and free bandwidth; reorder must let the new first item actually get resource. A display-only queue is a second lie.

Cancel also leaves a disposal question: what happens to the stretch already done. A partial upload, a partial transcode — after cancel, say whether it is dropped or kept as a half product. Unsaid, people will think “cancel rewinds everything” or “the chunk that already went up is still there”. If reorder pushes a running item down, that item should return to a resumable breakpoint, not be cancelled.

Where it stops holding

Hard uninterruptible ops (some firmware writes, a payment clearing once started) may refuse cancel, but must say so before submit, and mark the item uncancellable in the list — not a button that taps and does nothing. A shared task someone else submitted and you only watch: cancel rights follow identity. Maintenance the system submitted for you should be cancellable or deferrable, or “the user should be able to” does not hold. A single short item finishing in the foreground in seconds has nothing to reorder; cancel should still exist. If a miss-tap cancel would destroy long labour, confirm must be explicit, or a short window of undo-cancel offered.

Applying it

• Every unfinished task offers cancel; several offer reorder (drag or “move to front”).
• Cancel hits the executor: bandwidth and CPU yield within seconds. Fate of the completed stretch is written in the confirm.
• A pushed-down task keeps its breakpoint; it is not a cancel.
• How to check: queue three, move the last to the front, watch whether it starts occupying resource and whether the previously running one pauses and can continue. Cancel the middle one: it should leave in-progress on the list, and network activity should drop; a half file already written is either cleared or marked kept. Tap a firmware task marked uncancellable: that should have been told before submit, and the button should be unavailable rather than pretend-cancel on tap.

Related

• Same group: I3.12.1 Long tasks must survive quit and reboot · I3.12.2 Concurrent background work needs priority, not first-come-first-served · I3.12.4 Background resource use must be visible, or it looks like a leak
• Nearby: I2.06 Cancel during wait · I3.07 Background tasks
• Search terms: cancel job · reorder queue · preempt background