TelemetryManager.Dispose leaks Azure Monitor ActivityListener (only Shutdown(0)s, never disposes the providers)

[radical]

Summary

TelemetryManager.Dispose shuts down its TracerProvider instances but never disposes them, so the underlying ActivityListener registered on Aspire.Cli.Reported leaks for the rest of the process lifetime.

Repro

// src/Aspire.Cli/Telemetry/TelemetryManager.cs:202
public void Dispose()
{
    if (!_shuttingDown)
    {
        _azureMonitorProvider?.Shutdown(0);
        _profilingProvider?.Shutdown(0);
        _debugDiagnosticProvider?.Shutdown(0);
        // Dispose isn't used here because it always flushes telemetry and waits for completion.
    }
}

TracerProvider.Shutdown(timeoutMs) flushes pending spans and stops accepting new ones; it does not unregister the ActivityListener that the provider builder added to Activity.AddActivityListener. Only TracerProvider.Dispose() does that.

Expected vs. actual

Expected: After TelemetryManager.Dispose() returns, the ActivityListener it registered should be unregistered. After Shutdown(0) has run there is nothing to flush, so a subsequent Dispose() on each provider should be fast.

Actual: The listener stays alive process-wide. Every disposed TelemetryManager adds one more stale listener to Aspire.Cli.Reported.

Impact

• In production: non-issue. One TelemetryManager per CLI process; the process exits soon after.
• In the test process: this is the underlying cause of the microsoft.sample_rate race tracked by [Failing test]: Aspire.Cli.Tests.CliSmokeTests.MainReturnsExpectedExitCode\(args: \[\], expectedExitCode: 1\) #17450. Across many test classes, each disposed TelemetryManager leaves its listener behind. Subsequent parallel Reported activities trigger multiple stale samplers concurrently, both calling ActivityCreationOptions.SamplingTags.Add("microsoft.sample_rate", ...) on the same activity → InvalidOperationException: The collection already contains item with same key 'microsoft.sample_rate'.

PR #17451 (commit e126a1a) worked around this by opting the whole Aspire.Cli.Tests assembly out of Azure Monitor, but the underlying lifecycle bug remains: any future test (or production caller) that opts back in and disposes a TelemetryManager still leaks the listener. This was rediscovered in #17461 when new tests in TelemetryConfigurationTests bypassed the workaround by directly constructing TelemetryManager and resurrected the race (fixed in that PR by routing the new tests through BuildHostAsync).

Related

• [Failing test]: Aspire.Cli.Tests.CliSmokeTests.MainReturnsExpectedExitCode\(args: \[\], expectedExitCode: 1\) #17450 — the sample_rate race this leak surfaces
• Serialize CLI host tests to fix sample_rate race (#17450) #17451 — the test-process opt-out workaround (e126a1a)
• Add aspire --info to enumerate the running CLI's install + discovered installs + hives #17461 — surfaced this when new tests bypassed the workaround

[radical]

Suggested fix — call Dispose on each provider after Shutdown(0):

public void Dispose()
{
    if (!_shuttingDown)
    {
        _azureMonitorProvider?.Shutdown(0);
        _profilingProvider?.Shutdown(0);
        _debugDiagnosticProvider?.Shutdown(0);
    }
    _azureMonitorProvider?.Dispose();
    _profilingProvider?.Dispose();
    _debugDiagnosticProvider?.Dispose();
}

The current comment claiming Dispose "always flushes telemetry and waits for completion" is stale — after Shutdown(0) has run there is nothing left to flush, so the provider's Dispose is fast. The comment should be removed alongside the code change.

[joperezr]

🤖 Aspire triage pass — 2026-05-27 06:24 UTC

Area: area-engineering-systems (already applied; possibly also area-telemetry / area-cli — kept narrow)
Kind: bug (resource leak / test-infra root cause)
Repro: yes-minimal — code-level repro in the issue body with file/line citation (src/Aspire.Cli/Telemetry/TelemetryManager.cs:202) and a proposed patch in the follow-up comment
Affected version(s): main / current dev bits (no shipped-version impact called out)
Severity: S3 — production impact is nil (one TelemetryManager per CLI process, exits shortly after), but it is the root cause of the microsoft.sample_rate test race tracked by #17450 and re-surfaced in #17461; existing workaround #17451 (assembly-wide opt-out) holds

Urgency: ⚪ backlog — no milestone
Reason: S3 engineering / test-infra fix with an in-place workaround already merged; not a shipping-bits regression

Suggested owner(s): @joperezr (score 3), backup @karolz-ms (score 2)
Evidence:

• Issue author (@radical) is excluded per triage rules even though they own most recent area-engineering-systems work
• @joperezr merged Merge release/13.3 to main after v13.3.5 release (supersedes #17337) #17343 in area-engineering-systems (last 30d)
• @karolz-ms closed Some logs from Windows runs are saved in UTF-16 format #15771 as completed in area-engineering-systems
• No .github/CODEOWNERS entry specific to src/Aspire.Cli/Telemetry/ beyond general CLI ownership

Confidence: medium
Needs human?: no — author already proposed a concrete fix; just needs a non-author reviewer/owner to drive

Dry-run mode — no labels or milestone applied. Reply /triage apply to promote, or edit and reapply.

[radical]

@davidfowl @mitchdenny