A Cancellation Boundary for a Queued Catalogue Export
A user starts a catalogue export, changes their mind, and clicks Cancel. What do they expect? Probably that nothing will be produced. But if the export had already started, or already finished, that expectation may be false. This article proposes a cancellation boundary: a written statement of what Cancel does in each export state. It is a design proposal to adapt, not a description of an existing system.
Name the three states
Queued: the request is recorded, no work has begun. Running: work has begun, partial output may exist. Complete: a file has been generated and is available or has been delivered.
If your system has more states, such as Preparing or Uploading, map each one to the nearest of these three, and say which.
Decide what Cancel means in each state
Queued: Cancel can remove the request. No file should exist afterwards.
Running: Cancel may ask the work to stop. Stopping may not be instant, so there is a short period where the state is Cancelling. Partial files need a rule: discard them, or keep them labelled incomplete. Pick one.
Complete: Cancel has nothing to stop. The honest options are to hide the Cancel control, or to change it to Delete file, which is a different action with different consequences.
Queued-running-complete cancellation outcome table
Use this as the primary artifact, one row per state.
Queued. Button label: Cancel export. Result: request removed. Files remaining: none. Message: the export was cancelled before it started.
Running, stop honoured. Button label: Cancel export. Result: work stopped. Files remaining: per your rule, none or an incomplete file marked as such. Message: the export was stopped; say whether a partial file was kept.
Running, finished before the stop arrived. Result: the export completes anyway. Files remaining: the full file. Message: the export had already finished, so the file is available, with an option to delete it.
Complete. Button label: Delete file, not Cancel. Result: file removed from your side. Files remaining: copies the user already downloaded or that were emailed cannot be recalled. Say so.
Failed earlier. Cancel is not applicable. Show Retry or Dismiss.
Branching choices
If partial files are useful to people, keep them with a clear name suffix and a note. If partial files could be mistaken for a full catalogue, discard them. If exports are emailed or sent elsewhere, state that cancellation cannot recall a message already sent. If several users can see the same export, decide who may cancel and show the result to all of them.
Hypothetical worked example
Imagine a user requests an export of 4,000 products. At the moment of the click, the export is running and has written part of a file. The user clicks Cancel. The status changes to Cancelling. Two outcomes are possible. In the first, the work stops, the partial file is discarded under the chosen rule, and the status becomes Cancelled with the message that no file was kept. In the second, the final step had just completed, the status becomes Complete, and the message says the export finished before cancellation took effect, with a Delete file option. The interface should never say Cancelled while a downloadable file still exists.
Stop conditions
Pause the design if a state exists in which the message could be false, if Cancel can leave files the user is not told about, or if two states share the same message but different outcomes.
Acceptance checks
For each row of the table, trigger the state in a test environment and compare the displayed message, the file listing, and any notifications. All three should agree. Test the race: click Cancel as close to completion as possible, several times, and confirm the result is always one of the two documented outcomes. Confirm a repeated Cancel click does no harm. Record every mismatch as a defect against the table, then update the table only when the intended behaviour itself changes.