Fix ITelemetryModule singleton registration to support presence of keyed services #2908
Conversation
…hen keyed services are registered.
| /// <summary> | ||
| /// When working with IServiceCossection, it can store three types of Implementations: | ||
| /// ImplementationFactory, ImplementationInstance, and ImplementationType. | ||
| /// We want to be able to add a Singleton but only if a user hasn't already done so. | ||
| /// This class is to test all the various edge cases. | ||
| /// </summary> |
There was a problem hiding this comment.
The issue is as of 8.0.0 this summary is false.
There are new "keyed" forms of the possible registration types:
AddSingletonIfNotExists could be made smarter to understand the new shape. But that would require an 8.0.0 bump for M.E.DI/.A in Microsoft.ApplicationInsights.AspNetCore.
Easier IMO to just call into TryAddEnumerable and let it sort out what to do!
|
Sorry about the whitespace on diff! Blame VS 🤣 |
| @@ -37,6 +37,25 @@ namespace Microsoft.Extensions.DependencyInjection.Test | |||
|
|
|||
| public class AddApplicationInsightsTelemetryTests : BaseTestClass | |||
| { | |||
| [Fact] | |||
| public static void TelemetryModuleResolvableWhenKeyedServiceRegistered() | |||
There was a problem hiding this comment.
This test appears to pass even without your change.
I copied it locally and ran it in main branch.
There was a problem hiding this comment.
Interesting. It looks like without the fix, worker service can't find any registered ITelemetryHttpModule and the test fails. AspNetCore though finds RequestTrackingTelemetryModule registered so the test passes.
With the fix in place there are actually 7 ITelemetryHttpModules registered. I updated the tests to validate all 7 are found when keyed service is added to the mix.
There was a problem hiding this comment.
Just pushed updates to the test to improve them further. Added validation that a) DiagnosticsTelemetryModule is present in the final list and b) if the user supplied one we don't end up with 2.
|
The bug report is for .NET 8, but does it apply for other .NET versions and .NET Framework? |
Could impact all runtimes. All user needs to do is take a dependency on something which a) brings in M.E.DI 8.0.0+ and b) registers a keyed service. In the case of the bug report, it is actually |
|
@TimothyMothra @rajkumar-rangaraj I pushed a change to call I was looking through the history and trying to figure out why we had So my guess is we had |
| @@ -332,7 +312,7 @@ private static void AddCommonInitializers(IServiceCollection services) | |||
| private static void AddCommonTelemetryModules(IServiceCollection services) | |||
| { | |||
| // Previously users were encouraged to manually add the DiagnosticsTelemetryModule. | |||
| services.AddSingletonIfNotExists<ITelemetryModule, DiagnosticsTelemetryModule>(); | |||
| services.TryAddEnumerable(ServiceDescriptor.Singleton<ITelemetryModule, DiagnosticsTelemetryModule>()); | |||
There was a problem hiding this comment.
@TimothyMothra FYI I didn't make any other changes here but really all of the services.AddSingleton<ITelemetryModule, ...>(); calls should be TryAddEnumerable calls. If user only calls registration once everything will be fine. But if they call one of the "Add" extensions more than once, they'll get duplicates of all of these modules. Typically "Add" extensions should be safe to be called more than once which is accomplished by calling TryAddSingleton \ TryAddEnumerable 🤷
There was a problem hiding this comment.
|
I pinged @cijothomas offline to also take a look. He was involved in the previous PR #1886 |
|
Any updates on this? 👀👀 |
Fixes #2879
Relates to dotnet/extensions#5222
Changes
AddSingletonIfNotExistscustom implementation for detection of registered services and callTryAddEnumerableinstead because it understands keyed services added in 8.0.0