Undo the change to make the IServiceProvider in Configure scoped

[davidfowl]

Turns out people were capturing the IServiceProvider here to store in statics. Initially this change was made to make running EF migrations easier but then that pattern was moved into Program.Main. We've had several reports about this breaking things so we should consider reverting it.

Here's the initial change:
aspnet/Hosting#1106

We can consider this for a later patch as well.

[louislewis2]

Yes please, this has broken a key part of our system.

[davidfowl]

The workaround is trivial. Just FYI, assign app.ApplicationServices instead of injection IServicerProvider into Configure.

[louislewis2]

Sorry David, I do not quite follow the workaround. Is there a change required in my startup file, or should I me changing away from injecting IServiceProvider into those background jobs, and use something else?

[davidfowl]

Sorry David, I do not quite follow the workaround. Is there a change required in my startup file, or should I me changing away from injecting IServiceProvider into those background jobs, and use something else?

Today I assume you are doing this:

public void Configure(IServiceProvider provider)
{
    new BackgroundJob(provider).Run();  // Something like this?
}

There's like various ways to solve it:

Using IHostedService https://docs.microsoft.com/en-us/aspnet/core/fundamentals/host/hosted-services?view=aspnetcore-2.1

This is the preferred way.

Using DI and Configure:

public void Configure(BackgroundJob job)
{
    job.Run(); 
}

In this model you add BackgroundJob to the container and take services into the ctor.

Using ApplicationServices directly in Configure:

public void Configure(IApplicationBuilder app)
{
    new BackgroundJob(app.ApplicationServices).Run();  // Something like this?
}

[louislewis2]

Not quite,

The system runs on a super simple CQRS implementation.
At startup, various handles are registered dynamically into the dependency injection container.

The specific part that breaks is that CommandResultReactors get run the background, and as I mentioned it just worked.

So instead of manually calling the constructor as shown above, I rely in the DI container to do its magic.
On this line, you can see where the handlers are being resolved.

https://github.com/louislewis2/innovation/blob/master/src/Innovation.ServiceBus.InProcess/Dispatching/Dispatcher.cs#L477

On this line, you can see where the dispatcher starts running through the reactors.
https://github.com/louislewis2/innovation/blob/master/src/Innovation.ServiceBus.InProcess/Dispatching/Dispatcher.cs#L250

On this line, you can see where the handle methods are actually called.
https://github.com/louislewis2/innovation/blob/master/src/Innovation.ServiceBus.InProcess/Dispatching/Dispatcher.cs#L434

When running in the context of a web application, and requests are present. The exception will be thrown on this line.
https://github.com/louislewis2/innovation/blob/master/test/Innovation.SampleApi.Consumer/Handlers/Customers/Reactors/InsertCustomerCommandResultReactor.cs#L38

Because the reactors run behind the scenes, I always in them would request that a IServiceProvider is injected, so that I can create a scope and request things like database contexts from it safely.

It is there, that it now breaks with the object disposed exception.

I hope this helps explain the problem better, and hopefully why the sample code does not help me out to the point where I can implement a work around.

[davidfowl]

I hope this helps explain the problem better, and hopefully why the sample code does not help me out to the point where I can implement a work around.

Nope, sorry, I don't see how this breaks. What I need to see is what code activates your types. Where does that happen? If my sample code doesn't help you then I don't see how fixing this issue helps you.

[louislewis2]

The best way I can explain is that the dependency injection container, activate the types.
The types are discovered at application startup, by the simple class called runtime..

https://github.com/louislewis2/innovation/blob/master/src/Innovation.ServiceBus.InProcess/InnovationRuntime.cs#L231-L241

When a type is required, I simply request it from the di container.

https://github.com/louislewis2/innovation/blob/master/src/Innovation.ServiceBus.InProcess/Dispatching/Dispatcher.cs#L479

Nowhere is the constructor manually called, its all di dependent.

[davidfowl]

Nowhere is the constructor manually called, its all di dependent.

Sure.

This is getting much closer, but it's not all there yet. Where do you resolve the Dispatcher in the web case. I just need to see the composition root not all of the implementation details.

[louislewis2]

In a base class, inheriting from controller I resolve it like this.

private IDispatcher GetDispatcher()
{
    return this.HttpContext.RequestServices.GetRequiredService<IDispatcher>();
}

[davidfowl]

Great (I also found that code)! I have no idea how this specific change affects any of your code. If something is getting disposed it's because of something else. HttpContext.RequestServices is the scoped service provider and it goes away after the request is done.

[louislewis2]

Well, the application has been in production since January and has been working without hassles.
The only change, is the update to 2.1 and then we started finding this issue. I also ended up being puzzled, and then started looking online when I found the previous issue, where this issue started from. 🤷‍♂️

[davidfowl]

I'm not saying its not another issue or change, but it certainly isn't this one. Are you running things outside of the request scope that were started during a request scope?

[louislewis2]

The reactors could possibly still be running after the request has finished, possibly.
In the code base, they are used to add the result of a command and other key bits of information to a user interactions table.

[davidfowl]

My guess is that you were getting lucky before. The timing of when the per request service provider gets disposed changed in 2.1 but it's still "after the request is over". That has nothing to do with this issue. If you resolve a scoped service using RequestServices, it will get disposed when the request is over. It seems as though you are doing that here.

[louislewis2]

David, that explains it better than anything else. I am currently working making changes in code to fix the issue that we currently have in the code base, simply removing the reactors for now. Later on I will need to come up with a better fix.

Thanks for the time you put into this, it is greatly appreciated. 👍