When does asyncio log 'Task exception was never retrieved', and why so late?

### What 'retrieved' means When a coroutine driven by an `asyncio.Task` raises, the task completes in the *exception* state: the exception instance is stored on the task and an internal flag records that nobody has consumed it. Consuming means calling `Task.result()` — which re-raises it — or `Task.exception()` — which returns it. Awaiting the task calls `result()` for you. Any of these clears the flag. Nothing about a raise inside a task pushes it into your code: the loop has nowhere to deliver it, because the whole point of a task is that no caller is waiting. ### The finalizer path The report comes from the task object's `__del__`. If the unconsumed flag is still set, the finalizer assembles a context dictionary containing the message `Task exception was never retrieved`, the exception and the task, and passes it to the event loop's exception handler. The default handler logs at ERROR level on the `asyncio` logger, including the traceback, and — if the loop is in debug mode — the traceback of where the task was created, which is usually the more useful of the two. So the report is a *finalization* event, not a *failure* event, and that single fact explains everything odd about it. ### Why the timing is unpredictable CPython frees objects by reference counting, so in simple cases the task is destroyed as soon as the last reference drops — often immediately after the loop step that finished it, making the log line look prompt. But three things routinely push it around: * **Reference cycles.** A stored exception carries a traceback, which carries frames, which reference locals — cycles are the norm here. Then destruction waits for a generational collector pass, which happens on allocation pressure at an arbitrary later time. * **A reference you kept.** Fixing the collected-task problem by putting tasks into a long-lived set works — and if you never drain that set, the tasks are never finalized and the failures are *never* reported. The two pitfalls of fire-and-forget work pull against each other, and this is where the pair meets. * **Process exit.** If the interpreter shuts down before the object dies, you may get nothing at all, or a truncated report during finalization. The symptom in an incident review is a stack of identical errors clustered at a moment that has nothing to do with when the work actually failed. ### It is not the same as the never-awaited warning Keep the two apart. A `RuntimeWarning` about a coroutine that was never awaited means a coroutine object was created and never driven — the body never ran. `Task exception was never retrieved` means the opposite: the body ran, it failed, and nobody looked at the outcome. Confusing them sends you looking in the wrong place. ### Retrieving deliberately The cheapest correct pattern is a done callback that inspects the outcome: ```python def report(task: asyncio.Task) -> None: if task.cancelled(): return exc = task.exception() if exc is not None: log.error("task %s failed", task.get_name(), exc_info=exc) ``` Two details matter. The `Task.cancelled()` guard is required because calling `Task.exception()` on a cancelled task raises `asyncio.CancelledError` rather than returning it. And the callback only ever runs on a finished task, so `asyncio.InvalidStateError` — which `exception()` raises while a task is still pending — cannot occur here. Calling `exception()` marks the failure consumed, so the finalizer stays quiet and *your* log line, with your task name and your context, is the record instead. ### Why the default line is not good enough in production Even when it does fire, `Task exception was never retrieved` is a poor signal. It arrives on the `asyncio` logger, which many applications never configure or deliberately quiet; it arrives at finalization time rather than failure time, so it correlates with nothing; and it carries no application context — not which batch, which tenant, which file. Treat it as a smell that tells you a background task is unsupervised, and replace it with an explicit outcome handler that logs, counts, and decides whether the failure should abort the wider job. ### Interview framing The answer an interviewer is listening for has three beats: the exception is stored, not raised; the message comes from the finalizer through the loop's exception handler; and the timing therefore depends on garbage collection — up to and including never, if something keeps the task alive. A candidate who says the loop reports task failures as they happen has not yet operated a fire-and-forget service.