Por que os endpoints da API mínima estão esperando por tarefas?

Não acho que esteja explicitamente documentado. A documentação faz parecer que é permitido retornar apenas o Task(sem menção de que awaitele está usando ing ou que é um tipo especial):

Os pontos de extremidade mínimos oferecem suporte aos seguintes tipos de valores de retorno:

1. string- Isso inclui Task<string>e ValueTask<string>.
2. T( Qualquer outro tipo ) - Isso inclui Task<T>e ValueTask<T>.
3. IResultbaseado - Isso inclui Task<IResult>e ValueTask<IResult>.

Assim Taskcomo "qualquer outro tipo T", não um string, não implementando IResulttambém, então ele deve ser retornado como serializado json, e não explicitamente awaited.

Entretanto , os endpoints (métodos de ação do controlador ou lambdas de APIs mínimas) são convertidos em RequestDelegates:

public delegate Task RequestDelegate(HttpContext context);

antes de RequestDelegateFactoryserem conectados ao pipeline de middleware, onde você basicamente tem:

await requestDelegate();

Parte da mágica RequestDelegateFactoryé garantir que o comando acima tambémawait contenha qualquer tipo aguardável, como o que seu método/lambda está retornando. Veja também esta pergunta . awaitTask

Portanto Task, como um tipo de retorno tem um significado especial - a versão assíncrona dos voidmétodos de retorno síncronos/lambdas. Voltando à documentação acima

2. T( Qualquer outro tipo ) - Isso inclui Task<T>e ValueTask<T>.

No nosso caso Tis typeof(void)e Taskis esse contexto é realmente um Task<void>e não seu próprio Ttipo.

Acredito que essa interpretação seja corroborada pelo reconhecimento da equipe principal do asp.net de um bug na lógica do subpipeline do filtro .NET7+ ( os filtros do manipulador de rotas não manipulam todos os tipos de retorno ), no qual o Taskobjeto era encapsulado como um objeto normal ValueTask<object>e não era aguardado mais acima no middleware normal - o encapsulamento ValueTask<object>era aguardado - então era possível retorná-lo como jsonresposta, em vez awaitingdele:

Task Method() => Task.CompletedTask;
app.MapGet("/method", Method).AddFilter((c, n) => n(c));

Saída:

{"result":{},"id":54,"exception":null,"status":5,"isCanceled":false,"isCompleted":true,"isCompletedSuccessfully":true,"creationOptions":0,"asyncState":null,"isFaulted":false}

Descrição do bug:

Atualmente, os filtros envolvem o delegado do usuário em um método ValueTask<object?>antes de entregar a função à lógica de tratamento de rota normal. Isso causa problemas com métodos que não retornam objetos , como void, Task, Task<T>, etc.

então eles tiveram que mudar a RequestDelegateFactorylógica para realmente fazer isso awaitno delegado construído, e não depender do awaitpróximo nível superior no pipeline - código-fonte :

private static ValueTask<object?> ExecuteTaskWithEmptyResult(Task task) {
    static async ValueTask<object?> ExecuteAwaited(Task task) {
        await task;
        return EmptyHttpResult.Instance;
    }

    if (task.IsCompletedSuccessfully) {
        return new ValueTask<object?>(EmptyHttpResult.Instance);
    }

    return ExecuteAwaited(task);
}

Se quisermos retornar um Taskque não seja awaited para nós, podemos fazer uso de um lambda que retorna Task<Task>e um filtro.

app.MapGet("/taskreturn", () => Task.FromResult(Task.Delay(5000)))
.AddEndpointFilter(async (context, next) =>
{
    var result = await next(context); // next gives us Task<Task>
    // if we return result here it will be the uncompleted task
    // immediately
    //return result;

    if (result is Task task)
    {
        await task; // wait for 5 seconds
        //return task;
        // if we return here it will be the completed task
    }

    // or we can return something else
    return "from filter";
});

Está documentado: basta pesquisar um pouco. Culpe os mecanismos de busca por promoverem lixo em vez de conteúdo real!

MapGeté um método de extensão com dois padrões definidos em public static class EndpointRouteBuilderExtensions:

public static IEndpointConventionBuilder MapGet(this IEndpointRouteBuilder endpoints, string pattern, RequestDelegate requestDelegate);

public static IEndpointConventionBuilder MapGet(this IEndpointRouteBuilder endpoints, string pattern, delegate handler);

public delegate Task RequestDelegate(HttpContext context);

E o link do MSDocs:

https://learn.microsoft.com/en-us/dotnet/api/microsoft.aspnetcore.builder.endpointroutebuilderextensions?view=aspnetcore-9.0

Fiquei surpreso com o fato de que se um endpoint retorna uma tarefa, a solicitação não retorna até que a tarefa seja concluída

Você não pode retornar um Task. Se quiser um retorno no primeiro yield, retorne um null, não uma Task, para o endpoint.

Então você pode reescrever seu código assim, aguardando a conclusão da tarefa:

app.MapGet("/counter/incrementlater", IncrementLater);

//...

app.Run();

async Task IncrementLater(HttpRequest request, ICounterService counter )
{
    await Task.Delay(TimeSpan.FromSeconds(5));
    counter.Increment();
}

ou isto que retornaria no primeiro rendimento, ou seja, Task.Delay):

app.MapGet("/counter/incrementlater", IncrementLater);

//...

app.Run();

async void IncrementLater(HttpRequest request, ICounterService counter )
{
    await Task.Delay(TimeSpan.FromSeconds(5));
    counter.Increment();
}

Delegados de endpoint de API mínima se comportam da mesma forma que ações de controlador no MVC clássico. Portanto, se você estiver retornando um, Taskisso significa que seu endpoint/ação é assíncrono e que ainda há trabalho em andamento que precisará ser aguardado pelo framework para descobrir como será a resposta HTTP real.

Não há nada de especial na API Minimal aqui. Você parece estar confuso porque o delegado do endpoint não usa asynce , awaitmas nenhum dos dois é necessário em ações do controlador. Por exemplo, o seguinte é uma ação de controlador assíncrona perfeitamente adequada:

public Task<string[]> GetWeatherData()
{
    return _weatherService.GetWeatherDataAsync();
}

Semanticamente, isso também é o mesmo que o seguinte, que usa async/await:

public async Task<string[]> GetWeatherData()
{
    return await _weatherService.GetWeatherDataAsync();
}

Mas como _weatherService.GetWeatherDataAsyncjá retorna uma tarefa, você não precisa necessariamente executar a ação asyncnela await, mas pode simplesmente retornar a tarefa diretamente do serviço meteorológico (embora isso tenha alguns efeitos que podem ou não ser desejados).

Em ambos os casos, a ação retorna um Task<string[]>e é isso que fará o ASP.NET Core aguardar a ação para aguardar a resposta. O asyncapenas dirá ao compilador para fazer sua mágica para que você possa usar await. Mas ele é praticamente invisível (e irrelevante) para o tempo de execução.

Nos comentários, você mencionou "disparar e esquecer". Se você quiser que um endpoint (API mínima ou ação do controlador) se comporte como "disparar e esquecer" enquanto ainda executa algo em segundo plano, precisará mover essa ação explicitamente para segundo plano, gerando uma nova thread. Isso pode ser tão simples quanto usar Task.Run:

// I’m using actions here but this would be identical in Minimal API delegates
public async Task<IActionResult> GetWeatherData()
{
    // do not await the completion of this task
    _ = Task.Run(async () =>
    {
        await Task.Delay(5000);
        var data = await _weatherService.GetWeatherDataAsync();
        _logger.LogInformation("Received weather data in the background: {Data}", data);
    });

    await Task.Delay(1000);
    return Ok();
}

Ou para usar seu exemplo:

app.MapGet("/counter/incrementlater", (ICounterService counter) =>
{
    // do not await the completion of this task
    _ = Task.Run(async () =>
    {
        await Task.Delay(TimeSpan.FromSeconds(5));
        counter.Increment();
    }
});

Observe que, neste caso, o uso counterfuncionará, pois está registrado como um serviço singleton. Para outros escopos de serviço, especialmente um serviço com escopo (como um contexto de banco de dados EF), isso não funcionará e você precisará criar seu próprio escopo de serviço dentro da sua tarefa em segundo plano para evitar que o serviço com escopo seja descartado quando o endpoint/ação for concluído (o que ocorre antes da sua tarefa em segundo plano).