Task was destroyed but it is pending!

What this error actually means

This is asyncio telling you that work disappeared. A `Task` object was finalised while its coroutine had not finished, so whatever remained after the last `await` will never execute — no exception is raised anywhere, no caller is notified, and the log line is the only trace. It is a warning by severity and a silent-data-loss report by consequence.

There are two ways to get here and they are worth separating. The first is garbage collection: `asyncio.create_task` returns a task the loop only holds a weak reference to while it is waiting, so if your code keeps no strong reference, the task can be collected mid-flight at an arbitrary point. This is the one that produces genuinely random, low-frequency loss in production and is close to impossible to reproduce on demand.

The second is shutdown. `asyncio.run` cancels remaining tasks when the main coroutine returns, and a task cancelled while suspended never resumes. If that task was flushing metrics, committing an outbox row, acking a message or closing a file, the effect is the same as the first case: partially applied work with no error.

Notice what the message gives you for free — the coroutine name and the exact source line it was suspended at. That line tells you precisely which half of the operation completed and which half did not.

How to diagnose it

pending = [t for t in asyncio.all_tasks() if t is not asyncio.current_task()]
logger.warning("draining %d tasks: %s", len(pending), [t.get_name() for t in pending])

PYTHONASYNCIODEBUG=1 python -X dev -W error::RuntimeWarning app.py

grep -rn 'create_task(\|ensure_future(' --include='*.py' . | grep -v '=' 

The fix

Give every task an owner. The modern answer is `asyncio.TaskGroup` (Python 3.11+): tasks created inside the `async with` block are awaited at exit, exceptions propagate to the owner instead of vanishing, and a failure cancels siblings. It makes structured concurrency the default and removes both the collection hazard and the silent-failure hazard in one construct.

If you genuinely need work to outlive the request, keep a strong reference in a module-level `set` and discard it in a done callback: `task = asyncio.create_task(coro); tasks.add(task); task.add_done_callback(tasks.discard)`. This is the documented pattern for a reason — without it the task is collectable while suspended.

Build a real drain phase into shutdown. On SIGTERM, stop accepting new work, then await the outstanding tasks with a deadline, then cancel whatever is left and await the cancellations. In FastAPI or Starlette this belongs in the lifespan shutdown; in Kubernetes it needs `terminationGracePeriodSeconds` longer than the drain deadline, or the kernel kills you mid-drain regardless of what your code does.

Make the work durable rather than in-memory where losing it matters. If the follow-up is a webhook, a ledger write or an email, the reliable structure is to commit an intent row in the same transaction as the business change and have a separate consumer act on it. Then a cancelled task costs a delay instead of a lost event, because the record of what should happen survives the process.

Never swallow the completion of a task you started. A task whose exception is never retrieved logs `Task exception was never retrieved` at garbage-collection time — the same class of invisible failure as this warning, and the reason background errors can go unnoticed for months.

# Collectable while suspended; also loses any exception it raises
async def handle(request):
    asyncio.create_task(flush_metrics(request))
    return web.Response(text="ok")

# Owned, awaited, and exceptions surface at the owner
async def handle(request):
    async with asyncio.TaskGroup() as tg:
        tg.create_task(flush_metrics(request))
        tg.create_task(write_audit(request))
    return web.Response(text="ok")

# When the work must outlive the caller, hold a strong reference
_background: set[asyncio.Task] = set()

def spawn(coro) -> asyncio.Task:
    task = asyncio.create_task(coro)
    _background.add(task)
    task.add_done_callback(_background.discard)
    return task

# Drain with a deadline on shutdown
async def shutdown() -> None:
    if _background:
        done, pending = await asyncio.wait(_background, timeout=20)
        for task in pending:
            task.cancel()
        await asyncio.gather(*pending, return_exceptions=True)

How to stop it coming back

• Prefer `TaskGroup` over bare `create_task` everywhere; make unassigned `create_task` a lint failure
• Give tasks names (`create_task(coro, name="webhook-dispatch")`) so this warning identifies the subsystem instead of printing `Task-14`
• Make the shutdown drain a tested code path: send SIGTERM under load in CI and assert no pending-task warnings and no lost writes
• Set the container grace period above your drain deadline; a correct drain that gets SIGKILLed is still data loss
• For anything a user would notice losing, persist the intent transactionally rather than relying on an in-process task

FAQ

Related

Other errors engineers hit next to this one

• FATAL ERROR: Reached heap limit Allocation failed
• Unhandled promise rejection crashes the process
• ECONNRESET: socket hang up on a reused connection
• MaxListenersExceededWarning: possible EventEmitter memory leak
• EADDRINUSE: address already in use
• ERR_HTTP_HEADERS_SENT
• Event loop blocked by synchronous work
• pg client already connected or released twice