Código assíncrono no Startup ASP.NET Core: 4 maneiras de contornar o GetAwaiter (). GetResult ()

Antecedentes sobre a tarefa de trabalho

services
      .AddAuthentication()
      .AddJwtBearer(); 

public static AuthenticationBuilder AddJwtAuthentication(this AuthenticationBuilder builder, AuthJwtOptions options)
{
    var signingKeys = new List<SecurityKey>();

    var jwtBearerOptions = new JwtBearerOptions {Authority = options?.Authority};
    
    new JwtBearerPostConfigureOptions().PostConfigure(string.Empty, jwtBearerOptions);
    try
    {
        var config = jwtBearerOptions.ConfigurationManager
            .GetConfigurationAsync(new CancellationTokenSource(options?.AuthorityTimeoutInMs ?? 5000).Token)
            .GetAwaiter().GetResult();
        var providerSigningKeys = config.SigningKeys;
        signingKeys.AddRange(providerSigningKeys);
    }
    catch (Exception)
    {
        // ignored
    }

    builder
        .AddJwtBearer(options =>
        {
            options.TokenValidationParameters = new TokenValidationParameters
            {
                // ...
                IssuerSigningKeys = signingKeys,
                // ...
            };
        });
    return builder;
}

Estou incomodado com GetAwaiter (). GetResult (), mas a Microsoft não é

public override void Load() => LoadAsync().ConfigureAwait(false).GetAwaiter().GetResult();

O papel das tarefas assíncronas no início de um serviço da web

Problema: é necessário iniciar o serviço da Web para processar as solicitações de seus clientes, mas há um conjunto de algumas operações (relativamente) longas, sem as quais o serviço não pode responder ao cliente ou suas respostas estarão incorretas.

• Validação de configurações fortemente tipadas.
• Preenchendo o cache.
• Conexão preliminar ao banco de dados ou outros serviços.
• Carregamento de JIT e montagem (aquecimento de serviço).
• Migração de banco de dados. Este é um dos exemplos de Andrew Lock, mas ele próprio admite que, afinal, essa operação é indesejável ao iniciar o serviço .

Solução 1: uma solução funcional que pode confundir os herdeiros

public class Program
{
   public static async Task Main(string[] args)
   {
       IWebHost webHost = CreateWebHostBuilder(args).Build();

       using (var scope = webHost.Services.CreateScope())
       {
           //   
           var myService = scope.ServiceProvider.GetRequiredService<MyService>();

           await myService.DoAsyncJob();
       }

       await webHost.RunAsync();
   }

   public static IWebHostBuilder CreateWebHostBuilder(string[] args) =>
       WebHost.CreateDefaultBuilder(args)
           .UseStartup<Startup>();
}

Solução 2: incorporar operações assíncronas no DI

public interface IStartupTask
{
    Task ExecuteAsync(CancellationToken cancellationToken = default);
}

public static class ServiceCollectionExtensions
{
    public static IServiceCollection AddStartupTask<T>(this IServiceCollection services)
        where T : class, IStartupTask
        => services.AddTransient<IStartupTask, T>();
}

public static class StartupTaskWebHostExtensions
{
    public static async Task RunWithTasksAsync(this IWebHost webHost, CancellationToken cancellationToken = default)
    {
        //      DI
        var startupTasks = webHost.Services.GetServices<IStartupTask>();

        //   
        foreach (var startupTask in startupTasks)
        {
            await startupTask.ExecuteAsync(cancellationToken);
        }

        //    
        await webHost.RunAsync(cancellationToken);
    }
}

await CreateWebHostBuilder(args).Build().Run();

await CreateWebHostBuilder(args).Build().RunWithTasksAsync();

Solução nº 3: para quem mudou para o ASP.NET Core 3.x

public class WebHost
{
    public virtual async Task StartAsync(CancellationToken cancellationToken = default)
    {
        // ... initial setup
        await Server.StartAsync(hostingApp, cancellationToken).ConfigureAwait(false);

        // Fire IApplicationLifetime.Started
        _applicationLifetime?.NotifyStarted();

        // Fire IHostedService.Start
        await _hostedServiceExecutor.StartAsync(cancellationToken).ConfigureAwait(false);

        // ...remaining setup
    }
}

public class WebHost
{
    public virtual async Task StartAsync(CancellationToken cancellationToken = default)
    {
        // ... initial setup

        // Fire IHostedService.Start
        await _hostedServiceExecutor.StartAsync(cancellationToken).ConfigureAwait(false);

        // ... more setup
        await Server.StartAsync(hostingApp, cancellationToken).ConfigureAwait(false);

        // Fire IApplicationLifetime.Started
        _applicationLifetime?.NotifyStarted();

        // ...remaining setup
    }
}

Solução # 4: a história do exame de saúde e do Kubernetes

, , , . Kestrel , , « ».

Sempre determine a sonda de prontidão.

Se você não tiver uma análise de prontidão, seus pods se tornarão pontos finais de serviços quase que instantaneamente. Se o seu aplicativo demorar muito para se preparar para aceitar solicitações recebidas, as solicitações do cliente pelo serviço também iniciarão os pods que ainda não estão prontos para aceitar as conexões recebidas. Como resultado, os clientes receberão um erro "Conexão recusada".

public class LongTaskHostedService : IHostedService
{
    public async Task StartAsync(CancellationToken cancellationToken)
    {
            Console.WriteLine("Long task started...");
            await Task.Delay(5000, cancellationToken);
            Console.WriteLine("Long task finished.");
    }

    public Task StopAsync(CancellationToken cancellationToken)
    {...}
}

achados