Kotlin Coroutine Cancellation: Define What Stops During a Document Import

Cancelling a Kotlin coroutine requests that its work stop cooperatively. A document importer must define where it observes that request, what temporary resources it releases and which completed changes remain.

The official ensureActive reference explains that non-suspending work may need explicit cancellation checks. A cancel button therefore needs a workflow contract, not just a call to a cancellation API.

Divide the import into stages

Identify input acquisition, validation, parsing, record creation and final registration. Mark which stages are reversible and which create durable effects.

Scan Pro Receipt describes importing receipt material and exporting organized records, and declares Kotlin in the technology collection. Its internal coroutine design is not public in the listing. The workflow illustrates why “cancel import” needs an exact meaning.

If one record was already saved before cancellation, the interface should not imply that nothing happened.

Make long computation cooperative

Review loops and library calls that can run for a long time without suspension. Determine where cancellation can be observed safely.

A check between documents may be enough for small independent items but insufficient for one expensive parsing operation. Measure responsiveness with representative synthetic inputs and the actual libraries involved.

Do not assume moving code to a background dispatcher makes that code automatically interruptible.

Preserve cleanup paths

Temporary files and open resources need a defined cleanup policy. Kotlin's coroutine exception guidance distinguishes cancellation from ordinary failures.

Review broad exception handlers carefully. Treating cancellation as a generic recoverable error can accidentally restart work that the user explicitly stopped.

Keep cleanup bounded and appropriate to the resource. It should not become another indefinite operation that prevents the task from ending.

Describe the resulting state

Choose clear outcomes such as cancelled before saving, partially imported or completed before the cancellation request took effect. Use wording that reflects the actual result.

Retain enough operation identity to reconcile a return to the screen. A cancelled spinner is not evidence that a saved record was removed.

For batch imports, decide whether successfully completed items remain and how the user can identify them without processing the same source twice.

Test cancellation at useful boundaries

Trigger cancellation during acquisition, between items and shortly before final registration. Inspect durable records and temporary files after each case.

Repeat the operation with the same input and verify that recovery follows the stated policy. Use synthetic receipts and avoid placing private document contents in diagnostic logs.

The companion Kotlin archive compatibility guide examines the imported data's long-term contract.

Record both the requested cancellation time and the observed stopping point. This distinguishes a reasonable cooperative delay from work that ignores cancellation entirely.

Retain these cases when replacing parsers or changing batch size. The product promise belongs to the whole workflow, even when one implementation detail changes.

A trustworthy cancel action leaves the user with an accurate account of what stopped, what persisted and what can safely be tried again. For a batch task, show the completed item count alongside the stopped state so the user can plan the next attempt.