await inside InterceptAsynchronous<TResult>(IInvocation invocation)

[azresource]

Hello! I have a quick question regarding calling an awaited method inside InterceptAsynchronous. Apologies if this is documented somewhere, I did not see it specifically. The code in question looks like this, where _eventPublisher is an injected Service Bus Publisher:

        private async Task<TResult> InternalInterceptAsynchronous<TResult>(IInvocation invocation)
        {
            TResult result;
			.
			.
			.
                using (var transactionScope = new TransactionScope(TransactionScopeOption.Required, TransactionScopeAsyncFlowOption.Enabled))
                {
                    try
                    {
                        var invocationArguments = invocation.Arguments;

                        AggregateRoot aggregateRoot = invocationArguments
                            .Where(x => x != null && x.GetType().BaseType == typeof(AggregateRoot)).FirstOrDefault() as AggregateRoot;
                        CancellationToken cancellationToken = (CancellationToken)invocationArguments
                            .Where(x => x != null && x.GetType() == typeof(CancellationToken)).FirstOrDefault();

                        if (_eventPublisher != null && aggregateRoot != null && aggregateRoot.DomainEvents.Any())
                        {
                            await aggregateRoot.PublishDomainEventsAsync(_eventPublisher, cancellationToken);
                        }

                        invocation.Proceed();
                        var task = (Task<TResult>)invocation.ReturnValue;
                        result = await task;
                        transactionScope.Complete();
                    }
                    catch (Exception ex)
                    {
.
.
.
                    }
                    finally
                    {
                        transactionScope.Dispose();
                    }
                }
            }
		.
		.
		.
            return result;
        }

Running the code above causes the interceptor to be executed twice. If I change:

await aggregateRoot.PublishDomainEventsAsync(_eventPublisher, cancellationToken);
to
aggregateRoot.PublishDomainEventsAsync(_eventPublisher, cancellationToken).Wait();

The interceptor is run only once (although I do not want to introduce blocking calls). Although there do not appear to be any side effects of the method being invoked twice, I am trying to understand exactly why it happens, if it is intended, or if it is dangerous. Has anyone experienced similar behavior?

[JSkimming]

Are you using AsyncInterceptorBase? If so, then this is a known issue, which is documented here.

If you're not using AsyncInterceptorBase, then no, that's not supposed to happen. Which version of Castle.Core.AsyncInterceptor are you using? There was an issue in an earlier version.

[azresource]

Hi. I had noticed that in the documentation. I am using Option 1. All my classes implement IAsyncInterceptor and I am using version 2.1.0. The only thing I do slightly differently than examples is I use describe to describe my services (which I've used elsewhere with no issues):

var decorated = ServiceDescriptor.Describe(typeof(TInterface), serviceProvider =>
{
    var actual = serviceProvider.CreateInstance(descriptor);
    var proxyGenerator = serviceProvider.GetRequiredService<ProxyGenerator>();
    var interceptors = serviceProvider.GetServices<TInterfaceType>().ToArray();
    return proxyGenerator.CreateInterfaceProxyWithTarget(typeof(TInterface), actual, interceptors);
}, descriptor.Lifetime);

[JSkimming]

Can you provide a minimum example to demonstrate the issue? I'll give it a little time.

[azresource]

I will try to put a sample together asap (may be next week). We are using Azure Functions, so I want to replicate exactly what we are doing.

Thanks!

[JSkimming]

I understand, but being an Azure Function involves many moving parts. If it's possible to isolate this with a test or console app, it'll be much easier to diagnose.

Also, are you using Durable Functions? It's been a while since I used them, but Durable Functions do strange things with the synchronization context, which may affect async/await behaviour. This library uses ConfigureAwait(false) in a few places, which is necessary when running in ASP.NET .NET Framework (the .NET before .NET Core). Unfortunately, Durable Functions require you not to use ConfigureAwait or specify ConfigureAwait(true).

I found this SO answer after a quick search.
https://stackoverflow.com/a/57423382

[azresource]

We are not using durable functions. I'll try to get something together over the next day or so. I appreciate your help!

[azresource]

I cloned the repo and created a really crude test, where the Interceptor awaits another static method. It seems to throw things into a loop which is not what I expected, so maybe I didn't dig deep enough into the tests to understand how they are working. I've attached a zip for you here.

Castle.Core.AsyncInterceptor.zip

[JSkimming]

@azresource I think I've got it. You've highlighted a failing of the documentation. When you need to make an async call before calling Proceed(), then you must call IInvocationProceedInfo proceedInfo = invocation.CaptureProceedInfo(); prior to the async call. Then proceedInfo.Invoke(); afterward, instead of calling invocation.Proceed();

invocation.CaptureProceedInfo(); has an overhead, so if you don't need to make an async call, you can just call invocation.Proceed();. You can simplify this by always calling proceedInfo = invocation.CaptureProceedInfo(); then proceedInfo.Invoke(); Though it will be slower when you don't make an async call before invocation.

Here's your updated code. Please let me know if this resolves the issue. I'm going to update the documentation with this information. I'll also add some tests.

private async Task<TResult> InternalInterceptAsynchronous<TResult>(IInvocation invocation)
{
    TResult result;
    ...
    using (var transactionScope = new TransactionScope(TransactionScopeOption.Required, TransactionScopeAsyncFlowOption.Enabled))
    {
        try
        {
            var invocationArguments = invocation.Arguments;

            AggregateRoot aggregateRoot = invocationArguments
                .Where(x => x != null && x.GetType().BaseType == typeof(AggregateRoot)).FirstOrDefault() as AggregateRoot;
            CancellationToken cancellationToken = (CancellationToken)invocationArguments
                .Where(x => x != null && x.GetType() == typeof(CancellationToken)).FirstOrDefault();

            if (_eventPublisher != null && aggregateRoot != null && aggregateRoot.DomainEvents.Any())
            {
                // Must capture the proceed info prior to awaiting the async call.
                IInvocationProceedInfo proceedInfo = invocation.CaptureProceedInfo();
                await aggregateRoot.PublishDomainEventsAsync(_eventPublisher, cancellationToken);

                // This is the key to allowing the invocation to proceed asynchronously.
                proceedInfo.Invoke();
            }
            else
            {
                // If no async calls are made, we can just proceed as normal.
                invocation.Proceed();
            }

            var task = (Task<TResult>)invocation.ReturnValue;
            result = await task;
            transactionScope.Complete();
        }
        catch (Exception ex)
        {
            .
            .
            .
        }
        finally
        {
            transactionScope.Dispose();
        }
    }
}

[azresource]

That seems to have done the trick! I'll be doing more testing early next week with chained interceptors, but this looks great so far.

Thanks!