StopApplication shuts down host but not application

[Hoffs]

Describe the bug

When calling StopApplication() on IApplicationLifetime which is resolved from DI it only stops the host but application is kept alive and running.

To Reproduce

Using ASP.NET Core Web API template call StopApplication() on resolved interface in either controller or hosted service.
Startup:

        public static void Main(string[] args)
        {
            CreateWebHostBuilder(args).Build().Run();
        }

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

Stopping, where _serviceProvider is IServiceProvider and IApplicationLifetime is Microsoft.Extensions.Hosting interface.

var lifetime = _serviceProvider.GetService(typeof(IApplicationLifetime)) as IApplicationLifetime;
lifetime.StopApplication();

Expected behavior

Entire application shuts down.

Additional context

This is happening on dotnet 2.2 using WebHost to start the application.

[Tratcher]

Where did you call StopApplication from?

[Hoffs]

Called from inside HostedService that gets IApplicationLifetime injected on startup and also tried calling from inside a controller method with also injected IApplicationLifetime.

[Tratcher]

Can you upload a complete sample app?

[Hoffs]

Sorry for not responding sooner, but it was a programming error on our side. Some services that were being injected weren't disposed properly and kept the application from completely shutting down. Once we have implemented IDisposable's on them all issues went away and it works completely as expected.

[kstreichergb]

@Hoffs could you elaborate a bit what you did to solve this issue? I've run into the same problem. What is the proper way to ensure that both host and application are terminated (by force if necessary due to an uncatched exception)

[Hoffs]

@kstreichergb It was mostly that we had some resources (long-lived connections to other services with their own lifecycles) that needed to be closed and disposed, so that all sub-processes would exit before the application itself could exit. In our case it was RabbitMQ connections that werent being closed.