У меня есть следующий тестовый код WebAPI, я не использую WebAPI в производстве, но я сделал это из-за обсуждения, которое у меня было по этому вопросу:Асинхронный вопрос WebAPI

В любом случае, вот неправильный метод WebAPI:

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";
}

Я считал, что второе исключение ожидается, потому что, когдаawait завершается, скорее всего, он будет в другом потоке, гдеHttpContext.Current в качестве потоковой статической переменной больше не будет разрешаться соответствующее значение. Теперь, исходя из контекста синхронизации, на самом деле его можно заставить вернуться к тому же потоку после ожидания, но я не делаю ничего необычного в своем тесте. Это просто наивное использованиеawait.

В комментариях к другому вопросу мне сказали, чтоHttpContext.Current должен решить после ожидания. Есть даже другой комментарий по этому вопросу, указывающий на то же самое. Так что правда? Это должно решить? Я думаю нет, но я хочу авторитетный ответ на это, потому чтоasync а такжеawait достаточно новый, чтобы я не мог найти ничего определенного.

TL; DR: естьHttpContext.Current потенциальноnull послеawait?