Allow controlling of Invocation lifetime/scope

I’m using the SDK with Autofac dependency injection, and a very important scenario is to control lifetime scope of dependency injection and disposal when invoking a new function.

I used the IJobActivator interface to plug-in my Autofac container, however I cannot activate my types within a lifetime scope because there are no callbacks to dispose of the lifetime when the function invocation is finished (succeeded or not).

What I’m doing now is this:

        public T CreateInstance<T>()
        {
            var scope = _container.BeginLifetimeScope();
            return scope.Resolve<T>();
        }

The code above is bad because the lifetimescope is IDisposable, and will not be disposed automatically for me, and there is no way for me to determine when the activated instance has been disposed in order to dispose my lifetime scope.

I propose adding an ActivationContext parameter that is passed per activation (ideally invocation), that has the function invocation unique id. Then adding a Deactivate() method that takes the same context, to allow me to dispose of the lifetime I created earlier.

[drub0y]

So this seems to have stagnated, so I just wanted to chime in and say that I started down this path and found IJobActivator and was like 😀, but then quickly realized there was no ability to control scope and was like 😢.

I spent a little time looking at the SDK current design in hopes of offering some advice on how to maybe offer scoping, but unfortunately I’m not quite sure how to get out of this corner it’s current painted into right now. If backwards compatibility is a concern then the best option may actually be leaving IJobActivator the way it is, maybe even obsoleting it at some point, and instead revisiting the solution to DI from the top and offering it as a sibling option to the job activator approach. Then the upstream runtime logic could basically check if this “new” DI approach was configured and, if so, it would just ignore any existing activator concepts (maybe even throw and exception if both are used) and prefer the new DI approach instead.

[BishoyDemian]

Well, in theory, yes this alternative solution might work, however when the IJobActivator resolves the function class it should also resolve and inject multiple levels of dependencies that have several other lifetime/scope configurations (singletons, per invocation, per thread, etc.).

I personally don’t like my business function (or its class) to worry about or (even worse) control the scope/lifetime of its dependencies directly, as this goes against SRP. And my container already comes with lifetime management facility that I can use.

I’d be happy to undertake the work required here in a fork and submit a PR, however I wanted to kick start the discussion here first to gather as much information and feedback as possible before I start refactoring any code?