Краткий ответ

Исключение в такой asyncio.Task не передаётся автоматически вызывающей корутине: задача завершается с ошибкой самостоятельно. Если результат задачи никто не извлёк через await, result() или exception(), asyncio обычно сообщает об этом через обработчик исключений цикла с сообщением вроде Task exception was never retrieved.

Момент сообщения не фиксирован строго: чаще всего оно возникает при уничтожении объекта задачи сборщиком мусора или во время завершения event loop. Поэтому полагаться на такой лог как на механизм обработки ошибок нельзя.

Исторический контекст

Асинхронные библиотеки отделяют планирование фоновой работы от непосредственного ожидания её результата. Это позволяет запускать независимые операции, например сбор метрик или предварительное обновление кэша, не останавливая основную корутину.

Такое разделение требует отдельного правила для исключений: ошибка фоновой задачи не должна произвольно прерывать любую корутину, которая случайно запустила эту задачу. Поэтому исключение сохраняется внутри объекта Task до тех пор, пока его явно не извлекут или пока asyncio не обнаружит, что результат остался невостребованным.

Постановка проблемы

Вызов asyncio.create_task только планирует корутину на выполнение и возвращает объект задачи. Если этот объект потерян, вызывающий код больше не имеет удобного способа дождаться результата или обработать ошибку.

Последствия могут быть неприятными: основная операция продолжит работу, ошибка проявится лишь в логе с задержкой, а при неудачной настройке логирования команда может не заметить сбой фоновой функции. Для критичной работы это создаёт риск частично выполненной операции и несогласованного состояния.

Подробное решение

У Task есть состояние и результат. Если корутина завершается исключением, задача сохраняет это исключение; оно не выбрасывается в месте вызова create_task и не прерывает event loop.

Надёжный способ обработки — сохранить задачу и дождаться её результата:

import asyncio

async def failing_job():
    await asyncio.sleep(0)
    raise RuntimeError("сбой")

async def main():
    task = asyncio.create_task(failing_job())
    try:
        await task
    except RuntimeError as error:
        print(f"Ошибка обработана: {error}")

asyncio.run(main())

Здесь await task извлекает исключение и передаёт его в try. После этого asyncio не считает ошибку невостребованной.

Для фоновой задачи применяют отдельную функцию-обёртку, которая обрабатывает исключения внутри себя, либо добавляют callback завершения. В callback важно вызвать task.result() или task.exception(), иначе ошибка всё равно может остаться непрочитанной.

Если задача должна быть частью общей операции, лучше ожидать её вместе с другими задачами через asyncio.TaskGroup или явно контролировать результаты. В TaskGroup исключение одной дочерней задачи приводит к структурированной обработке группы: другие ещё выполняющиеся задачи отменяются, а ошибка передаётся при выходе из блока.

Важно отличать потерю ссылки от немедленной остановки задачи. Event loop обычно сохраняет слабые ссылки на задачи, поэтому приложение должно хранить сильную ссылку на долгоживущую фоновую задачу. Однако даже сохранённая ссылка не решает проблему обработки исключения: результат всё равно нужно получить или обработать.

Ситуация из практики

Сервис запускает фоновое обновление токена и не ожидает его, потому что основной HTTP-запрос должен завершиться независимо. При сбое обновления через несколько минут истекает старый токен, а сервис узнаёт о проблеме только из сообщения Task exception was never retrieved.

Рассмотрены три варианта:

Игнорировать предупреждение. Это проще, но ошибка превращается в скрытый отказ, а время её обнаружения зависит от сборки мусора и завершения event loop.
Сохранить задачу и периодически проверять её состояние. Это даёт контроль, но усложняет жизненный цикл и легко приводит к забытым проверкам.
Запустить фоновую корутину-обёртку, которая перехватывает ожидаемые исключения, пишет структурированный лог и инициирует обновление состояния сервиса. Этот вариант выбран, потому что он явно задаёт политику обработки ошибки и не смешивает её с логикой HTTP-запроса.

В результате сбой обновления сразу попадает в мониторинг, сервис может перейти в режим деградации, а завершение приложения корректно дожидается или отменяет фоновую работу.

Что кандидаты часто упускают

Передаётся ли исключение из задачи в корутину, которая вызвала create_task?

Нет. create_task возвращает объект Task и завершает вызов планированием корутины. Исключение будет передано только коду, который позже явно ожидает эту задачу или извлекает её результат.

Достаточно ли сохранить сильную ссылку на задачу, чтобы ошибка была обработана?

Нет. Сильная ссылка не даёт задаче исчезнуть раньше времени, но не извлекает её исключение. Нужно выполнить await task, вызвать task.result() или task.exception(), либо передать задачу в механизм, который гарантированно выполняет такую обработку.

Почему нельзя считать сообщение Task exception was never retrieved обычным способом обработки ошибок?

Это диагностическое уведомление о том, что программа не забрала исключение из завершённой задачи. Оно зависит от жизненного цикла объекта задачи и настроек обработчика исключений event loop, поэтому может появиться поздно или быть недостаточно заметным. Надёжная система должна обрабатывать ошибку в определённой точке жизненного цикла задачи и отдельно настраивать логирование и реакцию сервиса.