Запуск и забвение асинхронной задачи в MVC Action

Расслабьтесь, как говорит сама Microsoft (http://msdn.microsoft.com/en-us/library/system.web.httpcontext.allowasyncduringsyncstages.aspx):

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

Достаточно запомнить несколько простых правил:

• Никогда не ожидайте внутри (асинхронных или нет) событий void (поскольку они возвращаются немедленно). Некоторые события WebForms Page поддерживают внутри себя простые ожидания, но RegisterAsyncTask по-прежнему является наиболее предпочтительным подходом.

• Не ждите асинхронных методов void (поскольку они возвращаются немедленно).

• Не ждите синхронно в графическом интерфейсе или потоке запросов (.Wait(), .Result(), .WaitAll(), WaitAny()) для асинхронных методов, внутри которых нет .ConfigureAwait(false) для root await, или их корень Task не запускается с .Run() или не имеет явно указанный TaskScheduler.Default (поскольку графический интерфейс или запрос, таким образом, заблокируются).

• Используйте .ConfigureAwait(false) или Task.Run или явно укажите TaskScheduler.Default для каждого фонового процесса и в каждом библиотечном методе, который не должен продолжать контекст синхронизации — думайте об этом как о «вызывающем потоке», но знайте, что он не один (и не всегда на одном и том же), а может и вообще больше не существовать (если Запрос уже закончился). Это само по себе позволяет избежать наиболее распространенных ошибок async/await, а также повышает производительность.

Microsoft просто предположила, что вы забыли дождаться своей задачи...

ОБНОВЛЕНИЕ: Как Стивен ясно (каламбур) заявил в своем ответе, существует наследуемая, но скрытая опасность со всеми формами «выстрелил-забыл» при работе с пулами приложений, а не только для асинхронных /await, но и Tasks, ThreadPool и все другие подобные методы - они не гарантированно завершатся после завершения запроса (пул приложений может перезапуститься в любое время по ряду причин).

Вы можете заботиться об этом или нет (если это не критично для бизнеса, как в конкретном случае OP), но вы всегда должны знать об этом.

InvalidOperationException не является предупреждением. AllowAsyncDuringSyncStages — опасная настройка, которую я лично никогда не использовал.

правильное решение состоит в том, чтобы хранить запрос в постоянной очереди (например, в очереди Azure) и иметь отдельное приложение (например, рабочую роль Azure), обрабатывающее эту очередь. Это намного больше работы, но это правильный способ сделать это. Я имею в виду «правильно» в том смысле, что повторное использование IIS/ASP.NET вашего приложения не испортит вашу обработку.

Если вы абсолютно хотите, чтобы обработка выполнялась в памяти (и, как следствие, вы не против временной потери запросов), то по крайней мере зарегистрируйте работу с ASP.NET. У меня есть исходный код в моем блоге, который вы может зайти в ваше решение, чтобы сделать это. Но, пожалуйста, не просто хватайте код; пожалуйста, прочитайте весь пост, чтобы было ясно, почему это все еще не лучшее решение. :)

Ответ оказывается немного сложнее:

Если то, что вы делаете, как в моем примере, просто настраиваете длительную асинхронную задачу и возвращаетесь, вам не нужно делать больше, чем то, что я указал в своем вопросе.

Но есть риск: если кто-то расширит это действие позже, когда имело смысл сделать его асинхронным, то асинхронный метод «выстрели и забудь» внутри него будет случайным образом успешным или неудачным. Это выглядит так:

1. Метод выстрелил и забыл.
2. Поскольку он был запущен внутри асинхронной задачи, он попытается воссоединиться с контекстом этой задачи («упорядочить») при возвращении.
3. Если асинхронное действие контроллера было завершено, а экземпляр контроллера с тех пор был удален сборщиком мусора, этот контекст задачи теперь будет нулевым.

Будет ли это на самом деле нуль, будет зависеть от вышеуказанного времени - иногда это так, иногда это не так. Это означает, что разработчик может протестировать и обнаружить, что все работает правильно, отправить в производство, и все взорвется. Хуже того, ошибка, которую это вызывает:

1. NullReferenceException - очень расплывчато.
2. Брошенный внутрь кода .Net Framework, вы даже не можете войти внутрь Visual Studio — обычно это System.Web.dll.
3. Не перехватывается ни одной попыткой/поймать, потому что часть библиотеки параллельных задач, которая позволяет вам маршалировать обратно в существующие контексты попытки/поймать, является частью, которая дает сбой.

Таким образом, вы получите загадочную ошибку, когда ничего не происходит — исключения выбрасываются, но вы, вероятно, не осведомлены о них. Нехорошо.

Чистый способ предотвратить это:

[HttpPost]
public JsonResult StartGeneratePdf(int id)
{
    #pragma warning disable 4014 // Fire and forget.
    Task.Run(async () =>
    {
        await PdfGenerator.Current.GenerateAsync(id);
    }).ConfigureAwait(false);

    return Json(null);
}

Итак, здесь у нас есть синхронный контроллер без проблем, но чтобы гарантировать, что он по-прежнему не будет работать, даже если мы позже изменим его на асинхронный, мы явно запускаем новую задачу через Run, которая по умолчанию помещает задачу в основной ThreadPool. Если бы мы его ждали, он попытался бы связать его с этим контекстом, чего мы не хотим, поэтому мы его не ждем, и это дает нам неприятное предупреждение. Мы отключаем предупреждение с отключением предупреждения прагмы.