Trampas de async/await en C#: sync-over-async, async void y ConfigureAwait

Qué es

await sobre un Task incompleto captura el SynchronizationContext actual (o el TaskScheduler) y reanuda el resto del método allí. El artículo de buenas prácticas de Stephen Cleary en MSDN Magazine explica la consecuencia: si un contexto de interfaz de usuario o de ASP.NET clásico, que ejecuta un fragmento de código a la vez, está bloqueado en Task.Wait() o .Result esperando ese mismo método, la continuación nunca puede ejecutarse y el programa entra en interbloqueo; una aplicación de consola no entra en interbloqueo porque, como señala el artículo, su contexto planifica la continuación en el grupo de hilos en su lugar. ConfigureAwait(false) indica al awaiter que no reanude en el contexto capturado. Los métodos async void no tienen ningún Task que transporte una excepción, de modo que una excepción lanzada va directamente al contexto y quien llama no puede capturarla; el artículo reserva async void para los manejadores de eventos.

Por qué importa

ASP.NET Core no publica ningún SynchronizationContext, lo cual, según señalan las preguntas frecuentes de ConfigureAwait, reduce ahí la necesidad de ConfigureAwait(false), pero el sync-over-async sigue perjudicando en los servidores: un hilo bloqueado del grupo de hilos queda no disponible, y el tutorial de diagnóstico de .NET describe el agotamiento del grupo de hilos como el proceso en que el grupo añade hilos lentamente mientras el trabajo se acumula en cola y el uso de CPU se mantiene bajo. Tanto quienes vienen de JavaScript, donde es imposible bloquear sobre una promesa, como quienes vienen de Go, donde bloquear es barato, subestiman por igual este coste.

Cómo aplicarlo

• Asíncrono de principio a fin: en cuanto un método usa await, quienes lo llaman se convierten en async Task hasta el punto de entrada (acción de controlador, Main, manejador). No envolver una llamada asíncrona en un método síncrono con .Result.
• Devolver Task o Task<T> en lugar de void; reservar async void solo para los manejadores de eventos, y hacer que estos esperen (await) un método que devuelva Task y contenga la lógica.
• En el código de bibliotecas, poner ConfigureAwait(false) en cada await; en el código de la aplicación (controladores, manejadores de interfaz de usuario, métodos de prueba), dejar el valor predeterminado. Las preguntas frecuentes plantean exactamente esta división.
• Usar Task.Run para trabajo limitado por CPU que se quiere sacar del hilo que llama, no para E/S; la documentación de escenarios asíncronos separa ambos casos.
• Esperar (await) cada tarea que se inicia; un Task descartado oculta su excepción. Pasar un CancellationToken a través de cada firma asíncrona.

Trampas

Task.Wait y .Result envuelven las excepciones en AggregateException, mientras que await relanza directamente la primera excepción, como muestra el artículo de MSDN. ConfigureAwait(false) no cura un interbloqueo si a algún await de la cadena le falta, y las preguntas frecuentes advierten de que aún puede aparecer un contexto personalizado incluso en ASP.NET Core. Una lambda async pasada donde se espera un Action se convierte en async void. En .NET 9, el evento de traza WaitHandleWait señala las esperas de sync-over-async, tal como describe el tutorial de agotamiento.