Tengo el siguiente código de prueba WebAPI, no uso WebAPI en producción, pero hice esto debido a una discusión que tuve sobre esta pregunta: Pregunta asíncrona de WebAPI
De todos modos, aquí está el método WebAPI ofensivo:
public async Task<string> Get(int id)
{
var x = HttpContext.Current;
if (x == null)
{
// not thrown
throw new ArgumentException("HttpContext.Current is null");
}
await Task.Run(() => { Task.Delay(500); id = 3; });
x = HttpContext.Current;
if (x == null)
{
// thrown
throw new ArgumentException("HttpContext.Current is null");
}
return "value";
}
Hasta ahora, había creído que se esperaba la segunda excepción porque cuando se awaitcomplete, es probable que esté en un hilo diferente donde, HttpContext.Currentcomo una variable estática de hilo, ya no se resolverá en el valor apropiado. Ahora, según el contexto de sincronización, en realidad podría verse obligado a volver al mismo hilo después de la espera, pero no estoy haciendo nada elegante en mi prueba. Este es un simple e ingenuo uso de await.
En los comentarios de otra pregunta me dijeron que HttpContext.Currentdebería resolverse después de una espera. Incluso hay otro comentario sobre esta pregunta que indica lo mismo. Entonces, ¿qué es verdad? ¿Debería resolverse? Creo que no, pero quiero una respuesta autorizada sobre esto porque asyncy awaites lo suficientemente nuevo como para no encontrar nada definitivo.
TL; DR: ¿Es HttpContext.Currentpotencialmente nulldespués de un await?


