Separate a Cancelled Job from a Job That Already Started

A person clicks Cancel while a background export is leaving the queue. The screen says “Cancelled,” but a download appears a moment later. The problem is the promise: the interface reported an outcome before the system knew whether the work had stopped.

For a business application, agree on what cancellation means at each stage before approving the button. The fictional test below uses an export named EXP-42 and disposable records. It is a proposed acceptance exercise, not a report of work performed for a client.

Separate the request from the outcome

A successful cancellation request does not always mean that the job stopped. For example, AWS Batch documents that CancelJob can succeed without cancelling a job that has already reached STARTING or RUNNING. AWS provides a separate termination operation for those states. These are provider-specific rules; check the contract of the service your application actually uses.

Define your own user-facing states in plain language. “Cancellation requested” means that a request is awaiting confirmation. “Cancelled before processing” should require evidence that work did not proceed. “Stopped after starting” should explain any partial output. “Completed before cancellation” should preserve access to the result when the user is entitled to see it. An unknown result needs a visible verification step, not an invented success message.

Decide what can still be stopped

For EXP-42, ask the team to identify the last point at which the export can be prevented from becoming available. Stopping file preparation, preventing a download link from being issued, and removing an existing file are different actions. Write down which action the button requests and who may perform it.

Microsoft's asynchronous request-reply guidance separates the cancellation instruction from the later status update after the back end handles it, and asks designers to consider partial rollback or compensation. Use that distinction when agreeing on behavior. Stopping a task should not silently promise to reverse a notification or another external action that already happened.

Rehearse the moments on either side of the boundary

Use a test environment with controllable checkpoints so the outcome does not depend on clicking quickly. Have the tester record the job ID, the checkpoint, the cancellation response, the final stored status, and any resulting file or external test action.

• Still waiting: hold EXP-42 before the worker starts, request cancellation, release the checkpoint and verify that the agreed output is not created.
• Already processing: hold the worker after it starts. Confirm whether the supported behavior is to stop safely, finish a bounded step, or reject cancellation. Check the final outcome against that written rule.
• Already completed: request cancellation after the result exists. The screen must not relabel completed work as never performed.
• Response lost: interrupt the connection after sending the request. Reopen the same job and recover its current status; do not create a replacement export just to make the screen look responsive.
• Another operator viewing: open the same job in a second session. Both views should eventually report the same outcome and preserve who requested cancellation.

Give the operator a useful next action

Review the wording alongside the test results. “Cancellation requested; checking EXP-42” is appropriate while confirmation is pending. If processing finished first, show the actual result and explain whether a separate, authorized cleanup action is available. Avoid a generic Retry button that could start the business action again when the original result is uncertain.

Agree on a bounded waiting policy and an escalation owner. Include the job reference and last confirmed state in the support view. A refresh failure should remain distinguishable from a confirmed cancellation failure.

Approve evidence, then maintain the contract

The acceptance record should connect each scenario to the observed job state, visible message and actual output. Reject a pass based only on a successful HTTP response or a disabled button. Review this test again when the queue provider, worker steps or external side effects change.

Scope and cost depend on existing status tracking, safe stopping points, external service support and cleanup requirements. A short decision sheet describing those constraints gives a development team something concrete to estimate.

Discuss the cancellation rules and acceptance tests for your business workflow with Dynelink.

AI-generated conceptual illustration; not a client screenshot.