Quarkus Cache always executes or deadlocks on Kotlin coroutines

Describe the bug

When using @CacheResult on a Kotlin coroutine method the method is either always called (i.e. nothing is cached) or the method deadlocks.

No Caching

The following example method, the method is always called; no caching is done.

suspend getData(id: String): List<Data> {...}

This appears to be because the kotlin.coroutines.Continuation completion parameter is included in the cache key.

Deadlock

You can “fix” the inclusion of the completion parameter using the @CacheKey annotation. Unfortunately, this causes a deadlock.

Adding the annotation to the original example, causes any call to the cached method to deadlock.

suspend getData(@CacheKey id: String): List<Data> {...}

When calling the method the invocation happens twice, and the second time deadlocks waiting for the cached value to be fulfilled.

Expected behavior

Kotlin coroutine methods work the same way as synchronous or reactive methods.

Kotlin continuation parameters (kotlin.coroutines.Continuation) should always be excluded from the cache key with having to use the @CacheKey annotation.

Actual behavior

Either no caching happen or the thread deadlocks when calling a coroutine with the @CacheResult.

How to Reproduce?

1. Run the attached attached demo using ./mvnw quarkus:dev.
2. Calling https://localhost:8080/hello/test1 with return a new timestamp when it should be cached indefinitely after the first invocation.
3. Calling https://localhost:8080/hello/test2 will deadlock the request (and apparently the CLI along with it).

code-with-quarkus.zip

Output of uname -a or ver

macOS 12

Output of java -version

Java version “17” 2021-09-14 LTS Java™ SE Runtime Environment (build 17+35-LTS-2724) Java HotSpot™ 64-Bit Server VM (build 17+35-LTS-2724, mixed mode, sharing)

GraalVM version (if different from Java)

No response

Quarkus version or git rev

2.4.2 & 2.5.0

Build tool (ie. output of mvnw --version or gradlew --version)

No response

Additional information

No response

[mkouba]

@gwenneg @manovotn PR sent: https://github.com/quarkusio/quarkus/pull/22586 😉

[manovotn]

For the record - I assume that the only reason why we don’t ignore the non-static synthetic methods is that we expect that a framework can add a synthetic method that needs to be intercepted. But I’m not really sure this is something that should be supported.

You beat me to it. I was going to ask if this is something we want to support anyway. It might even be surprising that such method gets intercepted. Personally, I think we could ignore both cases but at least synthetic static methods can definitely be skipped.