Swift Task Cancellation Interview Questions: Cooperative Checks and Structured Lifetimes

Swift task cancellation is cooperative: cancelling a task records that its work is no longer wanted, but does not forcibly stop each instruction or automatically undo a completed side effect. A strong interview answer identifies who owns the task, where it observes cancellation, how resources are released, and when its owner can rely on completion.

This guide separates official Swift semantics from original experiments and design recommendations. The examples are preparation material rather than a reported employer assessment.

What happens when you call cancel()?

Cancellation is a state that running work can observe and respond to. Task.isCancelled lets an operation choose its response; Task.checkCancellation() throws CancellationError when the current task is cancelled. Neither requires every operation to stop in the same way. Apple cancellation-check reference

Imagine an export that has written three of ten chunks. A cancellation request does not erase those three writes. The operation needs a policy: delete a temporary artifact, preserve a resumable checkpoint, or record that a remote commit may already have happened. That policy comes from the export contract.

Do not equate await with a cancellation check. An asynchronous function may suspend without reacting to cancellation. A CPU-bound loop may never suspend at all. Ask which called API observes cancellation and where your own code should stop accepting further work.

A useful short answer is: “The owner requests cancellation; the operation cooperates at defined boundaries; the owner observes completion before treating cleanup as finished.” Each clause names a distinct event that can be tested.

Which tasks have structured lifetimes?

Structured children created through async let or a task group belong to a lexical scope. The scope coordinates their lifetime and cannot simply leave children running after it returns. Cancellation can propagate through this structure, while the work must still respond cooperatively. Structured concurrency proposal

By contrast, creating Task { ... } starts an unstructured task. Its inherited context can be useful, but creating it inside another task does not establish the same parent-child lifetime as a task-group child. A detached task is also unstructured and has different context inheritance. Swift concurrency chapter

For interview reasoning, draw a task tree and label the edges that actually propagate lifetime. Do not draw every task launched nearby as a child. If a screen stores an unstructured task handle, the screen or another explicit owner needs a stop policy and a way to avoid obsolete results.

Dropping a handle is not a cancellation strategy. It removes your convenient control surface without proving the operation ended. Similarly, retaining a handle does not guarantee the work belongs to the right lifecycle. Explain why the operation should survive navigation or stop with it.

Can a cancelled task still return a value?

Yes, if its implementation chooses to continue and return normally. This original fixture makes that distinction deterministic without a timing sleep. The gate has one waiter and a permanent open state; it is a testing aid, not a production cancellation primitive.

actor Gate {
    private var open = false
    private var waiter: CheckedContinuation<Void, Never>?

    func wait() async {
        if open { return }
        await withCheckedContinuation { waiter = $0 }
    }

    func release() {
        open = true
        waiter?.resume()
        waiter = nil
    }
}

func checkedResult(_ gate: Gate) async throws -> Int {
    await gate.wait()
    try Task.checkCancellation()
    return 42
}

func uncheckedResult(_ gate: Gate) async -> Int {
    await gate.wait()
    return 42
}

Create a task for each function with a separate gate. Cancel the task before releasing its gate. Awaiting the checked task's value throws; awaiting the unchecked task's value can return 42. Cancelling before the task reaches wait() does not invalidate the experiment because the gate retains its open state.

The gate deliberately does not interpret cancellation. It illustrates why a suspension point alone does not establish cooperation. Its single-waiter assumption matters: replacing one saved continuation with another would lose a waiter. A production multi-waiter abstraction needs a different registration and cancellation contract.

This experiment also separates request time from observed completion. After cancel(), the checked operation still needs the gate to open before it can reach the check. If a real dependency never resumes or acknowledges cancellation, the enclosing operation may remain unfinished.

Why does cancelAll() not make a task group finish instantly?

Consider an original race between two lookup providers. You take the first usable response, request cancellation of the remaining work, and return from the group body. The group still coordinates its children before the enclosing operation completes. A child that ignores cancellation can delay that exit.

The relevant timeline is not just “winner found.” It includes the cancellation request, losing child acknowledgment, bounded cleanup, child completion, and scope exit. This is why returning the fastest value from the group body does not by itself prove a strict overall latency bound.

Event in the original race	What the caller can conclude
First valid answer arrives	A candidate result is available.
Remaining children are cancelled	They have received a stop request.
A losing child observes cancellation	It can stop new work and release owned resources.
All children finish	The structured scope can finish.
The caller receives the result	The enclosing operation has completed its lifetime contract.

Ask what makes the slow provider interruptible. If it wraps a callback API, cancellation may need to cancel the underlying request and safely resolve the awaiting continuation. If it performs synchronous blocking work, a Swift cancellation flag cannot make that external operation interruptible by itself.

A timeout race built from a task group inherits the same issue. Cancelling the work branch when the timer wins does not guarantee instant scope exit. Describe the dependency's termination behavior before claiming a hard response deadline.

How should async let cleanup be explained?

An async let binding creates structured concurrent work whose lifetime is bounded by its scope. If a path leaves that scope without consuming all children normally, the language coordinates their cancellation and completion. Avoid treating unused bindings as abandoned background tasks. async let proposal

For an original page-loading example, image and metadata fetches form one response. If metadata fails and the page cannot be shown, the image fetch becomes unnecessary. Structured ownership expresses that relationship, but the image API still determines how quickly cancellation takes effect.

Discuss partial success before choosing a construct. If the image is optional and should be cached even after metadata fails, that may be a separate ownership requirement. Moving it to an unstructured task changes responsibilities: someone must now define caching, errors, shutdown, and duplicate work.

The interviewer may ask whether actor isolation makes these lifetime choices automatic. It does not. Isolation governs access to state; cancellation and task ownership govern which work remains relevant. Keep both contracts explicit when a result is produced across an actor suspension.

Where should checks and result guards go?

Put cancellation checks at meaningful work boundaries: before an expensive phase, periodically through a long loop, and before publishing a result whose owner may have changed. The right frequency balances wasted work against overhead; it is a product and workload decision rather than a magic interval.

For a search screen, cancellation and request identity solve related problems. A cancelled old search may still produce a value through a non-cooperative dependency. A generation number can stop that old result from replacing the newer one. Check ownership again when committing UI state.

On an actor, a suspension can allow another request to update the generation. Cancellation observed before the await does not protect the state after it. An original acceptance test should arrange A, then B, then A's late completion and assert that only B updates the visible result.

Do not turn cancellation into a misleading success value. Returning an empty list might be a deliberate API policy, but it can also make the UI display “no matches” when the request was withdrawn. Model cancellation, domain absence, and service failure according to what the caller needs to distinguish.

How do cancellation handlers bridge callback APIs?

withTaskCancellationHandler supplies a cancellation callback alongside an operation. The handler can ask an underlying transport to stop, but the operation still needs correct completion behavior. Apple's documentation describes a handler that may execute concurrently with the operation, so shared mutable registration state needs synchronization. Cancellation-handler reference

The difficult original case is cancellation arriving before the transport handle is stored. A naïve handler sees no handle, does nothing, and the operation then starts a request that nobody cancels. Another race has completion and cancellation both attempt to resume the continuation.

Define a small state machine before writing the wrapper: not registered, registered, cancellation requested, and terminal. Registration must observe an earlier cancellation request. Completion must claim the one terminal transition. Whichever path wins, the continuation is resolved at most once and the resource is released according to one owner.

A checked continuation helps detect misuse; it does not supply that state machine. An actor can coordinate asynchronous state, but a synchronous cancellation handler cannot simply assume an awaited actor call has already completed. Choose a synchronization mechanism that matches the callback requirements and document its ordering.

What does a useful cancellation test prove?

Test cancellation before work starts, during a suspension, between phases, and immediately before publication. Use gates or fake dependencies to establish the ordering rather than hoping a short sleep schedules tasks as intended. Assert the application result and resource state as well as the cancellation flag.

For structured work, verify that scope exit happens after each child's final owned cleanup. For unstructured work, verify that the designated owner cancels and observes the operation. Include a child that ignores cancellation long enough to expose an incorrect instant-exit assumption.

Cleanup is not automatically rollback. A local temporary file can be removed; a remote payment or write may require an operation identifier and reconciliation. A test that sees a task stop cannot prove that the external side effect never happened.

The saved experiment ran under Swift 6.3.3 in Swift 6 language mode on macOS. It observed the checked task throwing, the unchecked task returning 42 despite cancellation, and both group children completing cleanup before scope exit. Those are specific runtime observations, not a guarantee about every callback API.

Record Swift compiler version, language mode, and relevant isolation settings for reproducible examples. This article's fixture can be compiled separately from an iOS application. That verifies its task behavior without claiming device lifecycle coverage or every framework callback race.

Sources and Further Reading

• Apple: Task.checkCancellation
• The Swift Programming Language: Concurrency
• Swift Evolution: Structured concurrency
• Swift Evolution: async let
• Apple: withTaskCancellationHandler

Documentation checked September 30, 2026. Test cancellation against the concrete APIs and compiler configuration used by your application.