Eu tenho o seguinte código WebAPI de teste, eu não uso WebAPI em produção, mas eu fiz isso por causa de uma discussão que tive sobre essa questão:Pergunta do Async do WebAPI

De qualquer forma, aqui está o 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";
}

Eu tinha acreditado que a segunda exceção é esperada porque quando oawait completa, provavelmente será em um segmento diferente ondeHttpContext.Current como uma variável estática de thread não será mais resolvida para o valor apropriado. Agora, com base no contexto de sincronização, ele pode realmente ser forçado a voltar ao mesmo thread após o aguardo, mas não estou fazendo nada sofisticado em meu teste. Este é apenas um uso simples e ingênuo deawait.

Em comentários em outra pergunta me disseram queHttpContext.Current deve resolver depois de um aguardo. Há até outro comentário sobre essa questão indicando o mesmo. Então, o que é verdade? Deve resolver? Eu acho que não, mas eu quero uma resposta autoritária sobre isso, porqueasync eawait é novo o suficiente para não encontrar nada definitivo.

TL; DR: éHttpContext.Current potencialmentenull depois de umawait?