Test demonstrating Issue #25 - Root Cause: Calls to proceed after the first await are intercepted again

[ndrwrbgs]

Issue #25

It appears to be related to Castle.Core's AbstractInvocation's synchronous method Proceed().

This method uses a currentInterceptorIndex to tell when it's through all of the interceptors, and not utilize interception (instead using InvokeMethodOnTarget()). In the async case, this method is not being called twice nested (once to trigger the interceptor, and then again to invoke on the target at proceed()), but instead it's being called serially (either creating a new AbstractInvocation or it's exiting the finally in between the calls, allowing currentInterceptorIndex to reset). Therefore, Castle treats the proceed() as an interceptable call.

[JSkimming]

@ndrwrbgs I've spent a few hours on this one today, it's proving pretty gnarly. I'm digging into AbstractInvocation as you also must have.

I don't have any more time I'm afraid, I'll try and find to time to investigate further, but I can give no guarantees.

[JSkimming]

Fixed with #54

[ndrwrbgs]

If it's fixed, we should be able to merge this in now, right?
Ah, I see the commit included its own tests. Let me run this real quick and make sure that it also passes just in case!

[ndrwrbgs]

@JSkimming when I try running the repro test against master, it still produces an infinite interception. This seems to suggest that #54 didn't solve the failure in #26, demonstrating the issue from #25. Could you help me to figure out what I'm missing?

[ndrwrbgs]

It's helpful when you (me) know how to work (I do not) git and upstreams and actually pull the changes you're trying to validate, when you're trying to validate them.

[JSkimming]

@ndrwrbgs I use a bunch of aliases to simplify the workflow, they're largely based on this post by @haacked

I maintain this .gitconfig gist that I copy to all new machines I start using.

https://gist.github.com/JSkimming/9210830