Conflicts and cancellation are user-visible decisions

Some workflows let users edit parameters while work is pending. Decide whether an edit changes the current job or creates a new job. A report that began with one date range should not silently switch halfway through processing. Immutable job inputs often simplify audit and recovery. The user can cancel the old job and submit a new version if the product supports that action.

Ordinary editable records still need a concurrency contract. An expected version tells the server which state the user edited. A conditional update can reject a stale version and return a conflict. This prevents a quiet lost update, but it does not decide how to merge two changes. The interface needs to preserve the local draft, show relevant current values, and ask for an intentional choice where automatic merging would be unsafe.

Cancellation also needs a boundary. The browser sends a cancellation request. The server records it if the job is still cancellable. The worker checks it at safe points. A job that already published its final result may correctly return already completed. The interface should display the actual outcome, even when it differs from the user's requested action.

Avoid making stale client permission a shortcut. The server checks whether the caller can edit or cancel the specific job at execution time. An interface can hide unavailable controls to reduce confusion, but the protected operation still needs authorization. Explain denial without exposing another user's private job state.

A fictional report definition is version 12 with name Weekly spend. Editor A changes the name to Weekly cost. Editor B changes it to Team spend. A submits expectedVersion 12 and the server stores version 13. B then submits expectedVersion 12. The server returns conflict with an authorized view of version 13. B's draft remains Team spend and the interface shows that the current name is Weekly cost.

For job J8, cancellation arrives after final publication. The server returns succeeded at version 6. The browser says the export already completed and offers its result. It does not hide the result under a cancelled label.

An application precheck is insufficient when another writer can commit between read and update. The expected version must constrain the authoritative mutation, or an equivalent transaction protocol must protect the decision. This teaching SQL assumes a separately established authorized account scope:

1UPDATE report_definitions2SET name = :name, version = version + 13WHERE id = :id4  AND account_id = :authorized_account5  AND version = :expected_version6RETURNING id, name, version;

One returned row establishes the new stored version. Zero rows does not justify returning the submitted name as saved. The service distinguishes relevant outcomes under its disclosure policy: missing, denied, or stale. It may deliberately avoid revealing which applies to an unauthorized caller. The snippet omits schema details, input validation, and implementation of current permission checks; those remain required.

A lost success response introduces another uncertainty. The original expected version can become stale because the user's own write committed. A conflict alone cannot distinguish that success from another person's edit. A durable mutation identity or defined reconciliation read can resolve the uncertainty. Version checks prevent stale overwrites; operation identity supports replay. These mechanisms have separate jobs.

A report range has start day 10 and end day 20. Editor A changes start to 18. Editor B changes end to 15. Each edit is valid against the old record. Combining them yields start 18 after end 15. Different field names do not establish independence.

A merge policy compares changes to a common base, detects direct conflicts, then validates the complete candidate record. This case violates the range rule. Preserve B's draft and explain the conflict rather than silently accepting invalid output. Even if a database constraint enforces the rule, the interface still needs useful feedback. An exception alone is not a recovery experience.

A more permissive policy can merge independent display preferences, such as a description and an optional label, when their rules truly do not interact. State the domain assumption. The lesson is not that every concurrent edit needs manual work; it is that automatic merging requires a justified rule and validation of the final state.

Cancellation and completion compete at one authoritative transition boundary. In this workbook, a cancellable job can transition to cancellation-requested through a guarded database write. Completion binds prepared private output only if the job remains publishable and the attempt still owns its claim. If cancellation wins, the output is not exposed even if computation later finishes.

If completion wins first, cancellation returns the authoritative completed state. Explain that completion occurred before cancellation took effect. Do not display cancelled merely because the control was clicked. Deleting a result from local view does not reverse backend computation.

Cancellation request and confirmed cancellation also differ. A worker may need time to reach a safe stopping point. Status can remain cancelling until terminal cancellation is recorded. If work has external irreversible effects, their boundaries must be included. This exercise avoids such effects by keeping prepared output private until pointer binding.

A result can remain successfully computed after permission changes or a download grant expires. A fresh retrieval request checks current access and obtains a permitted route to the committed content. Recomputing solely because a temporary URL expired is unnecessary. A deliberately irrevocable share link would be a different capability contract with different limits.

The browser should not receive a permanent storage credential to simplify retrieval. Use the product's authorized download route or a bounded capability produced after authorization. A signed URL is not automatically a current permission check on every byte request; validity and revocation depend on the documented storage behavior.

One misconception is that expectedVersion is a merge algorithm. It only detects a changed basis. A second is that cancellation reverses time. It is a request whose result depends on the defined boundary and winning transition.

Exercise: private output exists; cancellation-requested v7 commits; the worker tries to bind using v6. Reject the stale transition, keep output private, and clean it up when no longer needed. The UI reports cancelling or cancelled according to durable state, never success from object existence. Award one point for guarded publication, one for state-accurate wording, one for private-output handling, and one for distinguishing request from confirmation.

For the converse schedule, completion commits first and cancel returns completed. Explain that outcome clearly. Both schedules belong in the test plan because a happy-path cancel demonstration covers only one ordering.

Two editors change different fields. Can the server always merge automatically? No. Fields may interact through business rules, and the product must define a safe merge policy. A valid answer proposes field-level conflict detection only where changes are independent and still validates the combined record. Award one point for rejecting unconditional merge, one for preserving drafts, and one for validating the resulting state.

Why not use last-write-wins for every form? A strong answer weighs simplicity against the cost of losing another person's change and identifies where the policy is acceptable. Follow up with a collaborative scratchpad versus billing settings. A weak answer claims timestamps solve intent. A conflict is useful information that lets the user decide; silently discarding it transfers the cost to them.