TelemetryService keeps every disposed AbpApplication alive #10942

Product / version: ABP Framework 10.7.0 (Volo.Abp.Core, Volo.Abp.AspNetCore). Also present on abpframework/abp dev at ec3203128f. Severity: memory leak; blocks large integration-test suites (out-of-memory).

Summary

Volo.Abp.Internal.Telemetry.TelemetryService.AddActivityAsync subscribes two handlers on every call, AppDomain.CurrentDomain.ProcessExit and Console.CancelKeyPress, and never removes them. Both lambdas share one closure with the Task.Run lambda, which uses _serviceScopeFactory, so the closure captures this. Each handler therefore roots:

static AppDomain.ProcessExit / Console.CancelKeyPress invocation list
  -> TelemetryService+<>c__DisplayClass7_0
  -> TelemetryService
  -> AutofacServiceScopeFactory
  -> root Autofac LifetimeScope (the whole container)
  -> ComponentRegistry -> ... -> AbpApplicationWithExternalServiceProvider

AbpApplicationBase calls AddActivityAsync(ActivityNameConsts.ApplicationRun) once per application at initialization. Shutdown() and Dispose() do not remove the handlers, so a disposed application, its container and every singleton in it stay reachable until the process exits.

Why it triggers in non-web processes

Telemetry runs only when IAbpHostEnvironment.IsDevelopment(). In a process with no web host (for example an AbpIntegratedTest<T> test host) whose module graph includes AbpAspNetCoreModule, AbpAspNetCoreModule.PreConfigureServices sets the environment from services.GetHostingEnvironment(). When no IWebHostEnvironment is registered, that returns an EmptyHostingEnvironment with EnvironmentName = Development. So every integration test runs in "Development", sends telemetry, and leaks its application.

Impact we measured

• Our host EF Core integration test assembly has about 470 AbpIntegratedTest tests, run serially in one process.
• Each test's application stays on the heap, about 17–19 MB per test, growing in a straight line.
• At about 476 tests the process reaches .NET's default GC heap hard limit (75% of a 10 GiB container, 7.5 GiB). The last tests fail with OutOfMemoryException while the Autofac container builds.
• A long-running web app pays less, but every AddActivityAsync / AddErrorActivityAsync call adds two more handlers that are never removed, so the ProcessExit invocation list grows for the life of the process.

Repro

1. Create a module that depends on AbpAspNetCoreModule and AbpAutofacModule. Do not register IWebHostEnvironment, and do not set Abp:Telemetry:IsEnabled.
2. In a loop: AbpApplicationFactory.Create<TModule>(o => o.UseAutofac()), Initialize(), Shutdown(), Dispose(), then keep a WeakReference to the application.
3. Run GC.Collect() and GC.WaitForPendingFinalizers(). Every WeakReference is still alive.
4. A heap root analysis (ClrMD GCRoot, or dotnet-gcdump) shows the path above. Setting Abp:Telemetry:IsEnabled=false makes the applications collectible.

Suggested fixes

1. Do not subscribe per call. Track pending telemetry tasks in one place, for example a static or per-application collection, and wait for them once on ProcessExit / CancelKeyPress or in OnApplicationShutdown. At the least, unsubscribe the handlers when telemetryTask completes.
2. Make sure the handlers capture only the task, not this. Today they share a closure with the Task.Run lambda.
3. Unregister telemetry handlers in AbpApplicationBase.Shutdown() / Dispose().
4. Consider not treating the EmptyHostingEnvironment fallback as "Development" for telemetry, or not sending telemetry from test hosts (AbpIntegratedTest, AbpWebApplicationFactoryIntegratedTest).

Our workaround

Test configuration sets Abp:Telemetry:IsEnabled=false in our AbpIntegratedTest base class (our module test bases already did).