Creating a scoped service with an HttpClientFactory

[twsouthwick]

I really like the idea of HttpClientFactory, but have found issues that the convenience methods assume you have singleton instances of the services required. For instance, the following fails:

public void ConfigureServices(IServiceCollection services)
{
    services.AddScoped<Test2>(); // Works if I switch this to AddSingleton
    services.AddHttpClient<Test1>();
    services.AddMvc().SetCompatibilityVersion(CompatibilityVersion.Version_2_1);
}

public class Test1
{
   public Test1(HttpClient client, Test2 test2)
   {
   }
}

public class Test2 { }

This results in the following:

InvalidOperationException: Cannot resolve scoped service 'WebApplication1.Startup+Test2' from root provider.

Can there be a way to set the lifetime of the scope? In this example, I want to set Test1 as a singleton.

[twsouthwick]

I found that I can do the following at it starts working:

var type = typeof(ITypedHttpClientFactory<>).Assembly.DefinedTypes.Single(t => t.Name.Contains("DefaultTypedHttpClientFactory"));
services.AddScoped(typeof(ITypedHttpClientFactory<>), type);

Is this ok to do?

[martincostello]

At least for message handlers, transient is required for things to work properly. Have you tried that instead?

[twsouthwick]

So this?

var type = typeof(ITypedHttpClientFactory<>).Assembly.DefinedTypes.Single(t => t.Name.Contains("DefaultTypedHttpClientFactory"));
services.AddTransient(typeof(ITypedHttpClientFactory<>), type);

[martincostello]

What I meant was to register Test2 as a transient, rather than scoped, dependency. Alternatively it may be related to being a nested type. I’m not at a computer at the moment so I don’t have an IDE to hand to go digging.

[twsouthwick]

That allows it to be resolved, but changes the semantics of the lifetime of Test2. I need it to be scoped so that everything within that request will have the same instance.

[theezak]

Injecting handlers is however subject to a memory leak (see other issue opened on that topic). The dependency container will keep a reference to the handler because the handler implements IDisposable. That prevents the handler from being released for garbage collection. A way around it is using a container that allows you to disable IDisposable tracking (for example ExternallyOwned () on autofac).

In general, you always need to keep on mind how IDisposable is handled by the container. The .net core container will keep references, but that was not actually immediately clear from the documentation.

The cache defines its own lifetime independent of the dependency scopes. If you want the scopes to control lifetime of the handler, you can just register your own (not using httpclientfactory).

[rynowak]

Assigning myself to take a look at this.

[rynowak]

So after some discussion here, I think the right thing to do is for us to create a scope for each handler chain created by the factory. The reason is that each handler chain is its own lifetime which is independent of other lifetimes in the application (per request in a web app).

This will allow things like transients to work as expected when they outlive the request (since they are resolved from the scope). This will also avoid piling up a bunch of transient disposables in the root scope.

---

The change here will be that you can no longer use scoped services to share state outside of the handler chain - since we're creating a new scope to build the handler chain. I don't have major concerns about this because as folks have pointed out, there are lots of problems right now with mixing delegating handlers + DI right now.

Another change that isn't as easy to reason about is that when using typed clients, the typed client will be resolved from a different DI scope than the handler chain. So if you're using scoped services as a way to pass data from a typed client to a delegating handler, that would no longer be supported. I don't have a big concern about this because HttpRequestMessage.Properties is provided for that purpose.

---

If you're familiar with this area please read and digest the above changes and let me know if you have any concerns.

/cc @theezak @twsouthwick @martincostello @glennc @davidfowl