Async lifecycles in DI

[Code-Grump]

Working through how we adapt to xunit, encountering it's IAsyncLifecycle I realised we could be offering asynchronous lifecycles for objects managed in BoDi - essentially supporting IAsyncDisposable and some kind of IAsyncInitializable interface. We'd need to make the Resolve mechanism ResolveAsync, but the value would be that users get their whole async lifecycle handled for them - when a dependency is resolved it's already initialized and when it's container falls out of scope it gets cleaned up asynchronously.

If we could combine this with something like declarative lifetimes, it could significantly reduce the need for test-run-, feature- and scenario-level hooks.

[gasparnagy]

This sounds like a good idea. We would need to evaluate the consequences of that and decide base on that.

I would be particularly interested whether this is:

• Supported by all platforms we support
• Does it need additional dependencies, if yes could it cause problems with the dependencies of the users themselves (what if the users' project needs another version of the same dep)
• Any backwards compatibility issues that we can imagine

[Code-Grump]

Looking at it right now, IAsyncDisposable is the only additional dependency we'd need from outside the Reqnroll codebase and this is available in all the versions of .NET Framework and .NET that we support, either baked in or available as a BCL library.

We'd probably want to introduce our own IAsyncInitializable interface - there's nothing yet defined from Microsoft of widely-adopted from a third-party library that would be appropriate for us to take a dependency on. The definition would be very simple though:

interface IAsyncInitializeable
{
    ValueTask InitializeAsync(CancellationToken cancellationToken = default);
}

The complexity of this is largely in the implementation within our DI's resolving algorithm and lifecycle-management:

• We need to add a new method of resolving a dependency and initialize any types that require it - I'm proposing ResolveInitializedAsync<T>(CancellationToken cancellationToken = default) to sit alongside Resolve<T>() which would not be modified.
• The new method would need to (as it resolves a type in the dependency graph) check if the type implements IAsyncInitializable and ensure InitializeAsync() is called once on the instance before it is resolved the first time.
• Make the container itself implement IAsyncDisposable and have its implementation look for instances which implement IAsyncDisposable, invoking their DisposeAsync() methods (and no longer invoking their IDisposeable.Dispose() implementation if they have one.)
• Change our use of the container to use these asynchronous methods instead of their synchronous counterparts.

All of this is additive behaviour - if the end-user doesn't implement either interface, there's no change in behaviour. If the user has a type which already implements IAsyncDisposable we'll now be calling it for them. There's the potential for some surprise there, but in the vast majority of cases it will be the correct thing.

[gasparnagy]

I see. But would Reqnroll call the ResolveInitializedAsync itself (when?) or would this be just something for the end users to call (when?)?

And what would happen if someone (Reqnroll or user) would try to resolve (explicitly or implicitly through the resolution chain of another object) and IAsyncInitializable with normal Resolve? Error?

[Code-Grump]

We would use ResolveInitializedAsync everywhere we current use Resolve - it may require some non-async code-paths become asynchronous, but as all the hooks are asynchronous, it should be a straightforward exercise.

If users still want to use Resolve that's probably ok until they hit something that requires initialization, at which point it should probably become an error.

[gasparnagy]

Oh. That makes sense. Would be interesting to check if there is any usage in Reqnroll that we cannot convert (easily) to async... hopefully not.