Fix AzureSdkDiagnosticListener from crashing user app #2293
+45
−16
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
AzureSdkDiagnosticListener component within DependencyTrackingTelemetryModule currently instantiates a new TelemetryClient, whenever a new Listener is created. (any statement like new DiagnosticListener("Azure.somename") will trigger this. All Azure sdks does this inside them)
In the event that the telemetryconfig used to initialize the module is disposed, but the DependencyTrackingTelemetryModule itself is not disposed, any attempt to create new AzureSdkListener() will result in an unhandled exception from the SDK, as AzureSdkDiagnosticListener will try to instantiate a new TelemetryClient using a disposed config.
This violates the SDK's error handling policy of never crashing customer application after a successful initialization.
This PR modifies AzureSdk listener to create a single TelemetryClient during initialization, and re-use it for every subsequent AzureSdkListeners. If config is disposed, telemetry is not tracked (must be obvious!), but this PR also prevents the unhandled exception.
Issues like #2195 will be fixed with this PR. However, the user code which is disposing telemetry config, without disposing the DependencyTrackingTelemetryModule must be fixed - but this is not a SDK bug, but user code issue and must handled by end users.