Python asyncio Interview Questions: Cancellation, TaskGroup, and Timeouts

An asyncio program can print the right output in a demo and still leak tasks, swallow cancellation, or wait beyond its advertised timeout. Interviewers often probe these boundaries because the syntax is short while the ownership rules are easy to miss.

The safest mental model is a tree of tasks with explicit owners. Cancellation is a request that raises CancelledError in a task at an opportunity to run. A timeout usually implements its deadline by cancellation. A structured task group waits for its children and contains their failures. Practise the concrete server side with Implement an asyncio-based chat server.

Evidence boundary: Behavior attributed to Task, TaskGroup, asyncio.timeout(), wait_for(), and shield() comes from Python 3.14 documentation checked on September 20, 2026. Code traces below are original examples. PracHub links are practice material, not predictions about one employer.

What happens when you call task.cancel()?

cancel() requests cancellation; it does not synchronously terminate arbitrary code. Python documents that CancelledError is raised in the task at the next opportunity. In ordinary coroutine code, that opportunity is an await. Cleanup therefore belongs in try/finally.

async def worker(resource):
    try:
        while True:
            item = await resource.next_item()
            await process(item)
    finally:
        await resource.aclose()

If you catch CancelledError, normally re-raise it after cleanup. Python notes that structured-concurrency components such as TaskGroup and asyncio.timeout() use cancellation internally and can misbehave when code swallows it. CancelledError directly subclasses BaseException, so a broad except Exception does not catch it.

An interview answer should say which task initiates cancellation, where it is observed, and when the caller waits for completion. Calling cancel() without awaiting the task can leave cleanup unfinished when the loop shuts down.

Why is TaskGroup different from a list of tasks?

TaskGroup is an asynchronous context manager that owns the tasks created inside it and waits for all of them on exit. Python documents that when one child fails with an exception other than CancelledError, the group cancels the remaining children, waits for them, and then raises an exception group containing the non-cancellation failures.

async def fetch_all(urls):
    async with asyncio.TaskGroup() as tg:
        tasks = [tg.create_task(fetch(url)) for url in urls]
    return [task.result() for task in tasks]

The return line runs only after every child has finished successfully. If one child fails, siblings receive cancellation and the context does not silently return a partial list.

Contrast that contract with manually calling create_task() and awaiting tasks one by one. If the first await fails, later tasks may continue unless you explicitly cancel and join them. asyncio.gather() has its own documented behavior; do not describe it as identical to TaskGroup merely because both start concurrent work.

How do exception groups change error handling?

Several children can fail before cancellation reaches them, or failures can occur during cleanup. TaskGroup combines eligible failures into ExceptionGroup or BaseExceptionGroup. Python's except* syntax lets code handle selected exception types while preserving others.

try:
    async with asyncio.TaskGroup() as tg:
        tg.create_task(load_config())
        tg.create_task(warm_cache())
except* OSError as group:
    report_io_failures(group.exceptions)

Do not flatten every error into one string and continue. Decide whether any child failure invalidates the operation, which failures are retryable, and what cleanup has completed. KeyboardInterrupt and SystemExit receive special handling in the documented group behavior.

Nested task groups are another useful interview boundary. Each inner group processes its own failures, while external cancellation of a parent still needs to propagate. The design goal is not merely “catch all exceptions”; it is preserving the task tree's ownership and cancellation count.

What does asyncio.timeout() actually time out?

Inside an asyncio.timeout(seconds) context, the current task is cancelled when the deadline expires. The context manager handles that internal CancelledError and raises TimeoutError outside the context. Python's documentation explicitly notes that the transformed TimeoutError can be caught outside the context manager.

try:
    async with asyncio.timeout(2.0):
        result = await request()
except TimeoutError:
    result = fallback()

The deadline covers the awaited work executed by the current task within the block. If that code starts an unowned background task and returns, the background task is not automatically part of the timeout's lifecycle. Put concurrent children in a TaskGroup inside the timeout when the operation owns them.

Timeout means the caller stopped waiting under a defined policy; it does not prove a remote server stopped work. For network protocols, discuss idempotency, request IDs, and retry behavior separately.

How does wait_for() differ?

asyncio.wait_for(aw, timeout) waits for an awaitable and cancels it when the timeout occurs. If given a coroutine, it schedules it as a task. Python documents that wait_for() waits for cancellation to complete, so observed wall-clock time can exceed the nominal timeout while the child handles cleanup.

This is a common interview trap: the deadline initiates cancellation; cleanup still consumes time. If cleanup has its own strict requirement, design and instrument it explicitly rather than assuming the outer timeout is a hard process kill.

Use a timeout context when one deadline should cover a block of related awaits. Use wait_for() when timing one awaitable expresses the ownership clearly. In both cases, state what is cancelled and who awaits it.

When is shield() appropriate?

asyncio.shield() protects the inner awaitable from cancellation of the awaiting coroutine. The caller still receives cancellation. This can be useful for a small operation that must finish, but it creates a separate lifetime that must be owned and referenced.

Do not shield an entire request merely to avoid writing cleanup. That can keep expensive work running after the client disappears and make shutdown unpredictable. Examples that may justify a narrowly bounded shield include committing an already-started durable write or finishing a protocol close, but the design still needs a deadline and an owner.

Also keep a strong reference to tasks you create. The event loop keeps weak references in some APIs, and “fire and forget” without a task registry, result callback, or shutdown join is not a robust ownership model.

How do queues and backpressure fit the answer?

An async producer that creates work faster than consumers can process it can exhaust memory even though no thread blocks. Use a bounded asyncio.Queue, await put(), and define shutdown semantics. Record when an item is accepted, when task_done() is called, and what happens to queued work on cancellation.

queue = asyncio.Queue(maxsize=100)

async def consumer():
    while True:
        item = await queue.get()
        try:
            await handle(item)
        finally:
            queue.task_done()

Production code also needs a sentinel or queue shutdown policy, consumer cancellation, and a join order. A timeout around queue.join() should not abandon consumers without cancelling and awaiting them.

Backpressure is an interview-quality follow-up because it connects coroutine scheduling to resource safety. Async code improves concurrency for waiting work; it does not create infinite capacity.

Which bugs should you reproduce with a trace?

Use timestamps and task names. Log task creation, cancellation request, entry into finally, cleanup completion, and final task state. Enable asyncio debug mode when investigating callbacks that block the loop or coroutines that were never awaited.

Test four cases: every child succeeds; one child fails; the parent is externally cancelled; and the deadline expires during child cleanup. Add a child that mistakenly suppresses CancelledError to demonstrate why the group stalls or behaves unexpectedly, then repair it by re-raising after cleanup.

For shared resources, test cancellation between acquisition and registration. An async context manager is safer than separate acquire() and release() calls because the ownership region is visible.

How should you answer the interview quickly?

Draw the task tree. Name the parent, each child, the failure source, and the cleanup owner. Then state the invariant: every created task is awaited or registered with an owner; every resource is released in finally or an async context manager; every timeout has a defined cancellation target.

Use a short trace instead of vague claims. “Child A raises; TaskGroup cancels B; B observes CancelledError at its next await; B runs finally; the group waits; then the parent receives an exception group.” That sequence is easier to evaluate than “TaskGroup handles errors.”

Mention the Python version when behavior or APIs matter. TaskGroup and asyncio.timeout() were added in Python 3.11, and the current 3.14 documentation records later refinements.

Practice related concurrency questions

These PracHub records train related skills and contain reported context. They are not a guarantee of future questions.

The reliable answer is a lifecycle, not a keyword list: create tasks under an owner, propagate cancellation, clean up in finally, join every child, and measure the deadline you actually promise.

Trace a graceful shutdown end to end

Consider a server with an accept loop, a bounded queue, and four workers. On shutdown, stop accepting new work first. Decide whether queued work is drained or rejected. Signal workers, give cleanup a bounded grace period, then cancel remaining tasks and await them. Close sockets and clients through their context managers. Only then stop the event loop.

Write the order as a testable trace. At time zero the parent receives a termination request. The acceptor exits. Producers stop adding items. queue.join() waits for accepted items under a grace deadline. The parent cancels remaining workers; each observes CancelledError, runs finally, and closes its resource. The TaskGroup joins them before the parent returns.

Test a worker that hangs during cleanup and one that raises while another is shutting down. Confirm that the process reports both the original failure and unfinished work without silently losing items. This exercise reveals why cancellation, timeout, and ownership cannot be discussed independently.

Also separate cooperative cancellation from a hard process boundary. Pure Python code that never awaits can block the event loop and delay every cancellation. Move truly blocking work to an appropriate thread or process executor, impose a separate operational timeout, and measure event-loop lag.

During review, find every create_task() call and answer three questions: who holds the reference, who observes the exception, and who cancels and awaits it at shutdown? Any unanswered call is a likely lifecycle bug. This mechanical audit often finds more real problems than debating coroutine syntax.

Sources and Further Reading

• Python 3.14: coroutines and tasks
• Python 3.14: asyncio exceptions
• Python 3.14: queues
• Python 3.14: developing with asyncio