GraphQL + Fault Tolerance fails to compile to native

[Ladicek]

Describe the bug

If my GraphQL endpoint injects a CDI bean that uses SmallRye Fault Tolerance, the resulting application can't be compiled to native.

A simple example is:

@GraphQLApi
public class MyEndpoint {
    @Inject
    MyService myService;

    @Query
    public Uni<String> get() {
        return myService.get();
    }
}

@Singleton
public class MyService {
    @Timeout
    public Uni<String> get() {
        return Uni.createFrom().item("Hello!");
    }
}

Native compilation fails with:

Error: Detected a started Thread in the image heap. Threads running in the image generator are no longer running at image runtime.  To see how this object got instantiated use --trace-object-instantiation=java.lang.Thread. The object was probably created by a class initializer and is reachable from a static field. You can request class initialization at image runtime by using the option --initialize-at-run-time=<class-name>. Or you can write your own initialization methods and call them explicitly from your main entry point.
Detailed message:
Trace: Object was reached by 
        reading field io.smallrye.faulttolerance.core.timer.Timer.thread of
                constant io.smallrye.faulttolerance.core.timer.Timer@4c21ed10 reached by 
        reading field io.smallrye.faulttolerance.ExecutorHolder.timer of
                constant io.smallrye.faulttolerance.ExecutorHolder@3ba3da36 reached by 
        reading field io.quarkus.arc.impl.InstanceHandleImpl.instance of
                constant io.quarkus.arc.impl.ContextInstanceHandleImpl@292cc76b reached by 
        reading field io.quarkus.arc.impl.LazyValue.value of
                constant io.quarkus.arc.impl.LazyValue@23d9c050 reached by 
        reading field java.util.concurrent.ConcurrentHashMap$Node.val of
                constant java.util.concurrent.ConcurrentHashMap$Node@21f67d6d reached by 
        reading field java.util.concurrent.ConcurrentHashMap$Node.next of
                constant java.util.concurrent.ConcurrentHashMap$Node@5a5c9a46 reached by 
        reading field java.util.concurrent.ConcurrentHashMap$Node.next of
                constant java.util.concurrent.ConcurrentHashMap$Node@75e355e reached by 
        indexing into array
                constant java.util.concurrent.ConcurrentHashMap$Node[]@19057ce2 reached by 
        reading field java.util.concurrent.ConcurrentHashMap.table of
                constant java.util.concurrent.ConcurrentHashMap@17d188c5 reached by 
        reading field io.quarkus.arc.impl.ComputingCache.map of
                constant io.quarkus.arc.impl.ComputingCache@657091a1 reached by 
        reading field io.quarkus.arc.impl.AbstractSharedContext.instances of
                constant io.quarkus.arc.impl.SingletonContext@482e4704 reached by 
        reading field io.quarkus.arc.impl.ArcContainerImpl.singletonContext of
                constant io.quarkus.arc.impl.ArcContainerImpl@3df0e5b4 reached by 
        reading field java.util.concurrent.atomic.AtomicReference.value of
                constant java.util.concurrent.atomic.AtomicReference@1867d2d9 reached by 
        scanning method io.quarkus.arc.Arc.container(Arc.java:41)
Call path from entry point to io.quarkus.arc.Arc.container(): 
        at io.quarkus.arc.Arc.container(Arc.java:41)
        at io.quarkus.smallrye.context.runtime.SmallRyeContextPropagationRecorder$2.get(SmallRyeContextPropagationRecorder.java:67)
        at com.oracle.svm.core.jdk.SystemPropertiesSupport.initializeLazyValue(SystemPropertiesSupport.java:216)
        at com.oracle.svm.core.jdk.SystemPropertiesSupport.getProperty(SystemPropertiesSupport.java:169)
        at com.oracle.svm.core.jdk.Target_java_lang_System.getProperty(JavaLangSubstitutions.java:290)
        at com.oracle.svm.jni.JNIJavaCallWrappers.jniInvoke_VARARGS:Ljava_lang_System_2_0002egetProperty_00028Ljava_lang_String_2_00029Ljava_lang_String_2(generated:0)

This is because SmallRye GraphQL asks the CDI container to instantiate all GraphQL beans during bootstrap (Bootstrap.verifyInjectionIsAvailable). In this case, the CDI container has to instantiate MyEndpoint, and to do that, it also has to instantiate MyService. To do that, the Fault Tolerance interceptor has to be instantiated, and all its runtime services, including a timer thread.

Expected behavior

Application compiles to native just fine. GraphQL defers instantiation of its beans to runtime.

Actual behavior

Application fails to compile to native. GraphQL instantiates its beans at build time.

How to Reproduce?

git clone https://github.com/Ladicek/quarkus-fault-tolerance-graphql.git
cd quarkus-fault-tolerance-graphql
mvn clean package -Dnative

Output of uname -a or ver

Linux argondie 4.15.0-156-generic #163-Ubuntu SMP Thu Aug 19 23:31:58 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Output of java -version

openjdk version "11.0.11" 2021-04-20 OpenJDK Runtime Environment (build 11.0.11+9-Ubuntu-0ubuntu2.18.04) OpenJDK 64-Bit Server VM (build 11.0.11+9-Ubuntu-0ubuntu2.18.04, mixed mode, sharing)

GraalVM version (if different from Java)

GraalVM CE 21.2.0

Quarkus version or git rev

2.2.3.Final

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

Apache Maven 3.8.1 (05c21c65bdfed0f71a2f2ada8b84da59348c4c5d) Maven home: /home/lthon/software/apache-maven Java version: 11.0.11, vendor: Ubuntu, runtime: /usr/lib/jvm/java-11-openjdk-amd64 Default locale: cs_CZ, platform encoding: UTF-8 OS name: "linux", version: "4.15.0-156-generic", arch: "amd64", family: "unix"

Additional information

No response

[quarkus-bot]

/cc @jmartisk, @phillip-kruger

[jmartisk]

This will be fixed by upgrading to SmallRye GraphQL 1.3.4. I have a Quarkus-side test that will go in with it.

[Ladicek]

Great to hear that!