GraphQL schema fail to generate in test

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

[aloubyansky]

I’ll have a look.

[aloubyansky]

Just FYI, this PR in JaCoCo https://github.com/jacoco/jacoco/pull/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.