GraphQL schema fail to generate in test

[jhautin]

Describe the bug

Currently, since quarkus 2.3.1 (including quarkus 2.4.0), when running mvn test, the tests can not run. This is due to graphql schema builder failing to build schema. It was working fine before ( quarkus 2.2.3 and above).

I suspect it is when involving an external library with an including a jandex index.

Note that test in dev mode is working fine.

The schema can not be build because the name of an argument is null.
graphql.AssertException: Name must be non-null, non-empty and match [_A-Za-z][_0-9A-Za-z]* - was 'null'

Expected behavior

The mvn test should be able to start the test and run fine.

Actual behavior

when running mvn test, no test are run as the quarkus application failed to initialize.

the complete error message

Caused by: java.lang.RuntimeException: Failed to start quarkus
	at io.quarkus.runner.ApplicationImpl.<clinit>(ApplicationImpl.zig:338)
	... 43 more

Caused by: graphql.AssertException: Name must be non-null, non-empty and match [_A-Za-z][_0-9A-Za-z]* - was 'null'
	at graphql.Assert.assertValidName(Assert.java:117)
	at graphql.schema.GraphQLArgument.<init>(GraphQLArgument.java:69)
	at graphql.schema.GraphQLArgument.<init>(GraphQLArgument.java:42)
	at graphql.schema.GraphQLArgument$Builder.build(GraphQLArgument.java:478)
	at io.smallrye.graphql.bootstrap.Bootstrap.createGraphQLArgument(Bootstrap.java:775)
	at io.smallrye.graphql.bootstrap.Bootstrap.createGraphQLArguments(Bootstrap.java:732)
	at io.smallrye.graphql.bootstrap.Bootstrap.createGraphQLFieldDefinitionFromOperation(Bootstrap.java:546)
	at io.smallrye.graphql.bootstrap.Bootstrap.addRootObject(Bootstrap.java:267)
	at io.smallrye.graphql.bootstrap.Bootstrap.addQueries(Bootstrap.java:216)
	at io.smallrye.graphql.bootstrap.Bootstrap.generateGraphQLSchema(Bootstrap.java:157)
	at io.smallrye.graphql.bootstrap.Bootstrap.bootstrap(Bootstrap.java:108)
	at io.smallrye.graphql.cdi.producer.GraphQLProducer.initialize(GraphQLProducer.java:34)
	at io.smallrye.graphql.cdi.producer.GraphQLProducer.initialize(GraphQLProducer.java:29)
	at io.smallrye.graphql.cdi.producer.GraphQLProducer.initialize(GraphQLProducer.java:24)
	at io.smallrye.graphql.cdi.producer.GraphQLProducer_ClientProxy.initialize(GraphQLProducer_ClientProxy.zig:299)
	at io.quarkus.smallrye.graphql.runtime.SmallRyeGraphQLRecorder.createExecutionService(SmallRyeGraphQLRecorder.java:27)
	at io.quarkus.deployment.steps.SmallRyeGraphQLProcessor$buildExecutionService-259019385.deploy_0(SmallRyeGraphQLProcessor$buildExecutionService-259019385.zig:1132)
	at io.quarkus.deployment.steps.SmallRyeGraphQLProcessor$buildExecutionService-259019385.deploy(SmallRyeGraphQLProcessor$buildExecutionService-259019385.zig:40)
	at io.quarkus.runner.ApplicationImpl.<clinit>(ApplicationImpl.zig:318)

How to Reproduce?

This archive contains 2 maven projects

• library: this is a simple api definition (in graphql)
• application: this is the application implementing the API.

to reproduce:

• install the library locally: mvn clean install
• test the application, it should work fine : mvn quarkus:dev
• run the test in dev mode, it should work fine
• test the mvn test. it should failed: mvn test

reproducers.zip

Output of uname -a or ver

OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"

Output of java -version

openjdk version "16.0.1" 2021-04-20 OpenJDK Runtime Environment GraalVM CE 21.1.0 (build 16.0.1+9-jvmci-21.1-b05) OpenJDK 64-Bit Server VM GraalVM CE 21.1.0 (build 16.0.1+9-jvmci-21.1-b05, mixed mode, sharing)

GraalVM version (if different from Java)

No response

Quarkus version or git rev

2.2.3/2.3.1/2.4.0

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

Apache Maven 3.8.1 (05c21c65bdfed0f71a2f2ada8b84da59348c4c5d) Maven home: C:\Program Files\apache-maven-3.8.1\bin.. Java version: 16.0.1, vendor: GraalVM Community, runtime: C:\Program Files\Oracle\graalvm-ce-java16-21.1.0 Default locale: fr_FR, platform encoding: Cp1252 OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"

Additional information

No response

[quarkus-bot]

/cc @jmartisk, @phillip-kruger

[phillip-kruger]

@jhautin I'll have a look a.s.a.p

[jhautin]

@phillip-kruger thanks

[jhautin]

Just adapt the code for Java 11. run it on graalvm for java 11 and got same issue. I attached the adapted code
reproducers11.zip
.

[phillip-kruger]

Ok, this is a weird one ! I do not think this has anything to do with GraphQL, but rather with the structure.
Maybe @aloubyansky can assist here ?

Alexey: When you build -skipTest and then ran the app, and do the request manually, everything works. Doing that same query in a test fails (before the app even starts, and it seems like the scanning exclude the library. If you look at the project structure, some code is in a separate lib.

Any tips ?

[aloubyansky]

I'll have a look.

[aloubyansky]

This is caused by the JacocoProcessor applying bytecode transformation.

[aloubyansky]

Method parameter names get lost which is causing this method parameter name being null issue.

[aloubyansky]

As a "workaround", commenting out the quarkus-jacoco extension will make the tests pass. The Instrumeter API we are calling is the original Jacoco one. So it probably has to be fixed there. Or we should compensate the missing method param names somehow.

[aloubyansky]

@stuartwdouglas fyi

[aloubyansky]

Calling Instrumenter.setRemoveSignatures(false) didn't help, just in case.
UPDATE: Ah, it's JAR signature, so not even related.

[stuartwdouglas]

@aloubyansky I see it working if you just add:

            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <configuration>
                <compilerArgs>
                    <arg>-parameters</arg>
                </compilerArgs>
                </configuration>
            </plugin>

to the library part of the reproducer. As far as I can tell the method names were never there in the first place.

[stuartwdouglas]

Ok, turns out Jandex is being clever and pulling this out of the local variable table if it was not compiled with this info, the local var table must be going missing.

[stuartwdouglas]

I think this can be closed as it is a Jacoco issue. You can work around it using the config I specified above.

[phillip-kruger]

Thanks @stuartwdouglas and @aloubyansky . Closing.

[aloubyansky]

Just in case, I asked about it on the JaCoCo mailing list https://groups.google.com/u/1/g/jacoco/c/ggU-DrjtrAM

[jhautin]

thanks for the workaround.

[aloubyansky]

Just FYI, this PR in JaCoCo jacoco/jacoco#1246 will make it work.
However, it shows that we are relying on debug symbols to be present in this case, which we probably shouldn't. Having a more reliable fallback would be good.