Spring AOP is not compatible with Kotlin Coroutines

[qiyuey]

1. the suspend fun may return COROUTINE_SUSPENDED
2. Spring AOP needs to filter COROUTINE_SUSPENDED because the fun did not actually return

[sdeleuze]

Seems to be a pre-requisite for #23575. Good candidate for Spring Framework 5.3.

[mkopylec]

I need this feature badly :)

[zymen]

Hi, also highly requested!

[wrotycz]

Yeah, that would help a lot!

[faderskd]

Need this feature too !

[gwieczorek-it]

Hi, I would love to see this feature implemented.

[rudykocur]

Sadly stumbled upon this bug :( I would need that badly

[sdeleuze]

Hey, here is an update on that topic. I have added @Transactional support for Coroutines via 5429c7a and I have provided some guidance on Spring Security side for similar support.

Those Spring Data and Spring Security supports are possible without any change on Spring AOP, and Coroutines support requires to be added at a Reactive-aware level which is not the case of Spring AOP if I am not mistakes, so I am not sure anymore this issue is relevant.

With this progresses in mind, please share your use cases requiring an update on Spring AOP if any.

[nenros]

I would ask if there is chance to fix it at all? Issue is really old and there isn't any visible progress here.

[sdeleuze]

This is a tricky one from a design perspective, but let see if we can move forward.
I will reach Spring Security team to try to get a feedback.

[RobertHeim]

any updates? seems to block a lot of other issues downstream

[jun-wu-tw]

any updates? seems to block a lot of other issues downstream

Hey, RoberHeim.
I find a workaround for coroutine with Aspectj, but I don't remember the link.
You can refer to the following code. Hope it can help you out. 🙏

1. Add the extensions

val ProceedingJoinPoint.coroutineContinuation: Continuation<Any?>
    get() = this.args.last() as Continuation<Any?>

val ProceedingJoinPoint.coroutineArgs: Array<Any?>
    get() = this.args.sliceArray(0 until this.args.size - 1)

suspend fun ProceedingJoinPoint.proceedCoroutine(
    args: Array<Any?> = this.coroutineArgs
): Any? = suspendCoroutineUninterceptedOrReturn { continuation ->
    this.proceed(args + continuation)
}

fun ProceedingJoinPoint.runCoroutine(
    block: suspend () -> Any?
): Any? =
    block.startCoroutineUninterceptedOrReturn(this.coroutineContinuation)

2. Add the Continuation point cut

    @Pointcut("args(.., kotlin.coroutines.Continuation)")
    fun suspendFunctionPointCut() {

    }

3. Usage (combine your personal with Continuation point cut)

    @Around("YourCustomPointCut() && suspendFunctionPointCut()")
    fun handleGenericSystemErrors(joinPoint: ProceedingJoinPoint): Any? {
        return joinPoint.runCoroutine {
            val result = joinPoint.proceedCoroutine()!!
            return@runCoroutine result
        }
    }

[RobertHeim]

@jun-wu-tw the problem is not that we need it in our code base, but it must be integrated in spring itself to solve downstream issues:

• AuthorizationManager[Before/After]ReactiveMethodInterceptor doesn't support Kotlin coroutines spring-security#12080
• Kotlin reactive apps using coroutines broken after upgrade to spring security 6.0.2  spring-security#12821 and esp. this comment

[sdeleuze]

After working on the Spring Security repro created by @jzheaux, I may have found a potential way to handle this.

I managed to fix the repro with some changes on Spring Framework side that you can see in this draft commit. In a nutshell, at InvocableHandlerMethod level, when a proxified suspending function is detected, we just invoke the regular Java code path with method.invoke(getBean(), args) and defer the invocation of CoroutinesUtils#invokeSuspendingFunction to org.springframework.aop.support.AopUtils#invokeJoinpointUsingReflection.

That way, proxified suspending functions return their Mono counterpart, allowing MethodInterceptors to deal with those like if it was reactive methods returning Mono. This slightly changes how Coroutines interceptors work, but they were broken for a lot of use cases and I think this also makes them more consistent with the rest of the Coroutines support in Spring.

It is possible to test this Spring Framework branch by cloning it, running ./gradlew publishToMavenLocal and then using this repro branch that should now work correctly.

As a consequence, I tentatively plan resolving this issue in Spring Framework 6.1.0-RC1. Since a lot of Spring developers are waiting for the resolution of this issue, please provide your feedback on this proposal if possible.

@jhoeller @rstoyanchev @poutsma @jzheaux Please let me know if you have any concern about the proposed solution.

[sdeleuze]

Looks like we are going to have to do something more evolved in order to support non reflective use cases and make this less intrusive from the caller perspective.

[sdeleuze]

Initial support pushed, please test Spring Framework 6.1.0-SNAPSHOT and let me know how it goes.

@jzheaux Please let me know how it goes on Spring Security after you refine the support to avoid the multiple subscription issues we discussed on your repro.

@mp911de @rstoyanchev I refined reactive transactional and HTTP service interface support to leverage those generic capabilities, tests are green but please ping me if you see related reports on Coroutines support.

[tonnoz]

@jun-wu-tw sir, you saved the day, thank you so much