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

При уничтожении Tokio runtime незавершённые async-задачи, созданные этим runtime, обычно немедленно удаляются и не получают гарантии завершения. Их локальные значения уничтожаются, но код после последней точки ожидания может не выполниться. Это поведение относится именно к Tokio; язык Rust сам по себе не задаёт единую политику завершения всех async runtime.

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

Асинхронные задачи отделены от обычных потоков: они управляются runtime, который хранит очереди задач, планирует их опрос и обеспечивает работу реактора ввода-вывода. Поэтому runtime должен определить, что делать с задачами при завершении собственного жизненного цикла.

Такой подход позволяет быстро завершать сервис или тестовый контекст без ожидания каждой фоновой задачи. Обратная сторона — простого запуска задачи недостаточно для гарантии выполнения; завершение должно быть явно согласовано с владельцем задачи.

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

Фоновая задача может выполнять запись, отправлять сообщение или освобождать внешний ресурс. Если уничтожить runtime раньше, чем задача достигнет Poll::Ready, Tokio удалит задачу, и ожидаемая операция может не завершиться.

Нельзя считать вызов spawn эквивалентом гарантированного фонового процесса. Если результат задачи не нужен, это не означает, что её работа переживёт runtime или завершится до выхода из функции.

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

Tokio хранит async-задачи внутри runtime. При его уничтожении незавершённые async-задачи удаляются: их future уничтожаются, поэтому выполняются обычные деструкторы уже существующих локальных значений, но выполнение future не возобновляется и не доводится до следующей точки завершения.

Минимальный пример показывает отсутствие гарантии вывода:

use tokio::runtime::Runtime;

fn main() {
    let rt = Runtime::new().unwrap();
    rt.spawn(async {
        println!("задача могла начаться");
        tokio::time::sleep(std::time::Duration::from_secs(1)).await;
        println!("это не гарантировано");
    });
    drop(rt);
}

Даже первое сообщение не гарантировано: runtime может быть уничтожен до первого опроса задачи. Второе сообщение не гарантировано тем более, поскольку задача ожидает таймер и удаляется при завершении runtime.

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

Есть важное исключение по классу задач: операции, запущенные через spawn_blocking, не прекращаются простым abort, если уже начали выполняться. При завершении runtime Tokio может ждать такие операции; ограничение времени ожидания прекращает ожидание runtime, но не останавливает уже выполняющийся блокирующий код.

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

HTTP-сервис запускает задачу, которая асинхронно сохраняет аудит события, а затем сразу завершает runtime после отправки ответа. Возможны три подхода.

Игнорировать JoinHandle. Это минимально меняет код, но запись может быть потеряна при остановке процесса.
Дожидаться каждой записи перед ответом. Это повышает надёжность, но увеличивает задержку запроса и связывает доступность ответа с хранилищем.
При штатном завершении перестать принимать новые запросы, дождаться активных задач с таймаутом и только затем уничтожить runtime. Этот вариант обычно выбирают для graceful shutdown: он сохраняет предсказуемость, а таймаут ограничивает время остановки.

Если запись критична, дополнительно используют надёжную очередь или транзакционный outbox. Тогда уничтожение runtime не считается механизмом доставки, а является лишь частью контролируемого жизненного цикла приложения.

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

Вопрос: Гарантирует ли JoinHandle выполнение задачи, если его сохранить, но не вызвать await?

Ответ: Нет. Само хранение дескриптора не заставляет задачу завершиться и не предотвращает уничтожение runtime. Гарантия появляется только при корректном ожидании задачи и сохранении runtime достаточно долго для этого ожидания.
Вопрос: Можно ли считать уничтожение future полноценной отменой операции во внешней системе?

Ответ: Нет. Уничтожение future прекращает дальнейшее выполнение Rust-кода этой future, но уже отправленный сетевой запрос, запись в драйвере или операция удалённого сервиса может продолжиться. Для корректной отмены нужны свойства конкретного API: поддержка отмены, идемпотентность, транзакция или компенсационная операция.
Вопрос: Чем завершение Tokio runtime отличается от вызова abort у отдельной задачи?

Ответ: abort адресно помечает конкретную async-задачу для прекращения и приводит к удалению её future при обработке отмены. Уничтожение runtime прекращает управление всеми его async-задачами сразу. В обоих случаях завершение задачи не означает откат внешних побочных эффектов, а для уже выполняющегося spawn_blocking-кода abort не останавливает синхронное выполнение.