Deduplication of components providing multiple services can break overrides of services depending on order of resolution.

[PTwr]

Describe the Bug

Upon further debugging, the feature for deduplication of (open generic) components ignores overrides when assigning component to its other services, which breaks overrides of services resolved later on

When resolving for 'IAits overrideAis properly resolved and assigned, but then its earlier registration fromAB : IA, IBis assigned as implementation forIA(accidentally not causing an issue), andIBwhich still had no implementations resolved causing it to erroneously resolve toABinstead of its override ofB`.

---

Possibly related, or same, as #1464 - not related, my full usecase simply exposed both issues at the same time

Non-generic equivalent is working correctly, issue occurs only for open-generics.

For component exposing multiple services as open generic interfaces, not every override works.
There appears to be some caching going on under the hood, which goes haywire in entertaining use cases.
Issue is seemingly non-deterministic in real systems, as it depends on order of resolution.

From debugging linked issue in free time, and quick peek at same breakpoints when debugging test for this issue, it seems to boil down to Autofac guts mixing up open generic interfaces that look similar and thus succumbing to auto-illusion during further resolutions.

It was fun thing to debug and distill into simple tests :)

Steps to Reproduce

public class ReproTest
{
    interface IA { } interface IB { }
    class A : IA { } class B : IB { }
    class AB : IA, IB { }

    interface IA<T> { } interface IB<T> { }
    class A<T> : IA<T> { } class B<T> : IB<T> { }
    class AB<T> : IA<T>, IB<T> { }

    [Fact]
    public void Worky()
    {
        var builder = new ContainerBuilder();

        builder
            .RegisterType<AB>()
            .As<IA>()
            .As<IB>();
        builder
            .RegisterType<A>()
            .As<IA>();
        builder
            .RegisterType<B>()
            .As<IB>();

        var container = builder.Build();

        var a = container.Resolve<IA>();
        var b = container.Resolve<IB>();

        // works as expected
        Assert.True(a is A);
        Assert.True(b is B);
    }

    [Fact]
    public void NotWorky()
    {
        var builder = new ContainerBuilder();

        builder
            .RegisterGeneric(typeof(AB<>))
            .As(typeof(IA<>))
            .As(typeof(IB<>));
        builder
            .RegisterGeneric(typeof(A<>))
            .As(typeof(IA<>));
        builder
            .RegisterGeneric(typeof(B<>))
            .As(typeof(IB<>));

        var container = builder.Build();

        var aOfInt = container.Resolve<IA<int>>();
        var bOfInt = container.Resolve<IB<int>>();

        // resolve B first this time with another generic parameter
        var bOfStr = container.Resolve<IB<string>>();
        var aOfStr = container.Resolve<IA<string>>();

        // first resolution for given generic parameter is resolved correctly
        Assert.True(aOfInt is A<int>);
        Assert.True(bOfStr is B<string>);

        // services resolved later return AB<T> instead of overrides
        Assert.True(bOfInt is B<int>);
        Assert.True(aOfStr is A<string>);
    }
}

Expected Behavior

Open-Generics should behave the same as Non-Generic, and hallucinations should be reserved for AI not DI :)

Workaround

Registering AB<> separately for IA<> and IB<> solves the issue, but causes multiple instances of AB<> for each registration unless custom activator is provided (eg. AB<> registered as self, then resolved from ctx for its interface registration).

Dependency Versions

Autofac: 8.4.0 and 7.1.0

[tillig]

Interesting. Similar to that one, your fastest fix will come in the form of submitting a PR.

[PTwr]

Interesting. Similar to that one, your fastest fix will come in the form of submitting a PR.

That will take some time, sadly. The complexity of open generic resolution in modern DI frameworks is quite an interesting read.
Gotta fix the prod first ;)

I am fairly sure I know what the underlying issue is, and how to fix it, I just need more time to read through Autofac codebase to find where it is, and time is always in short supply.
Well, at least here its is clear that there is bug. 1464 itself might be argued as a feature.

[PTwr]

I found some time to debug the issue and it appears that

• Issue occurs only for Open-Generics
• Registration is innocent, issue is resolution-time
• RegistrationSources are innocent, they receive invalid registrationAccessor
• Issue somewhere in RegisteredServiceTracker, or deeper

I've added mock RegistrationSource and some ToString's to enhance EyeBall mk1 and thats what I've seen:

First resolution, for IA<int>

Second resolution, for IB<int>

ServiceRegistrationInfo.Implementations holds cached values before new ones.

Upon seeing the complexity of GetInitializedServiceInfo I've decided to perform info dump before digging further.

[PTwr]

The core of the issue is in:

Autofac/src/Autofac/Core/Registration/DefaultRegisteredServicesTracker.cs

Line 328 in ab7ca4d

// This ensures that multiple services provided by the same

This ensures that multiple services provided by the same component share a single component (we don't re-query for them)

The code in question is not executed for non-generic cases.

Upon resolution of IA<T>, it queries source of AB<T> which provides both IA<T> and IB<T>. That source is then added to sourceImplementations of both services.

Because it happens after IA<T> has been properly resolved to A<T>, AB<T> is safely added at the end of list.
For IB<T>, however, the sourceImplementations is still empty (null), thus AB<T> becomes first item, and later on B<T> as added at the end of list, thus causing the issue.