Open GregJohnStewart opened 2 years ago
/cc @aloubyansky, @evanchooly, @gastaldi, @gsmet, @maxandersen
This has proven a pretty annoying bug to track down. Pretty sparse information all around, and I have passing integration tests that both ensure restarting of the test instance (via different test resources), and creating tests dynamically in the same manner as the cucumber one
When launching a @QuarkusIntegrationTest
, there is a log file named quarkus.log
that is created in the build directory. Does that by any chance contain any useful information?
Pretty sparse there too;
2022-04-26 09:02:58,942 gen-dev-box quarkus-run.jar[5286] INFO [com.ebp.ope.dri.AppLifecycleBean] (main) The application is starting...
2022-04-26 09:02:59,052 gen-dev-box quarkus-run.jar[5286] INFO [io.quarkus] (main) open-qm-driver-server 1.0.1-SNAPSHOT on JVM (powered by Quarkus 2.8.1.Final) started in 1.105s. Listening on: http://0.0.0.0:8081
2022-04-26 09:02:59,053 gen-dev-box quarkus-run.jar[5286] INFO [io.quarkus] (main) Profile prod activated.
2022-04-26 09:02:59,054 gen-dev-box quarkus-run.jar[5286] INFO [io.quarkus] (main) Installed features: [cdi, config-yaml, hibernate-validator, resteasy-reactive, resteasy-reactive-jackson, smallrye-context-propagation, smallrye-health, smallrye-openapi, vertx]
2022-04-26 09:03:01,660 gen-dev-box quarkus-run.jar[5286] INFO [io.qua.htt.access-log] (executor-thread-0) 127.0.0.1 - - 26/Apr/2022:09:03:01 -0400 "GET /hello HTTP/1.1" 200 23
2022-04-26 09:03:08,554 gen-dev-box quarkus-run.jar[5286] INFO [com.ebp.ope.dri.AppLifecycleBean] (Shutdown thread) The application is stopping...
2022-04-26 09:03:08,663 gen-dev-box quarkus-run.jar[5286] INFO [io.quarkus] (Shutdown thread) open-qm-driver-server stopped in 0.148s
Looks like it's the log from the run previous to the one that fails to start
Looking into the case where the cucumber tests are the only ones to run, it looks like there is a bug in the config provider used by the ConfigInstantiator
;
In the regular tests, the ConfigProvider
returns a SmallRyeConfig
, while for the Cucumber tests a io.quarkus.test.junit.RunningAppConfigResolver
is returned, which causes the class cast exception.
I'm a bit stumped. After an amount of debugging, this method is often called, and normally comes back with the SmallRyeConfig
. but under certain (yet unknown) and consistent circumstances, returns the RunningAppConfigResolver
, that causes the issue.
The actual getting of the Config object happens in org.eclipse.microprofile.config.spi.ConfigProviderresolver
though, so that might make it harder to fix as it's outside of Quarkus
Perhaps @radcortez may have some comments on that config resolution part.
@famod and @jaikiran Are also listed on the git blame.
Noticing that in most usages of the config object, it could just be assigned as a generic Config
, rather than a SmallRyeConfig
. There is at least one usage that requires SmallRyeConfig
, but maybe we could work around that somehow?
The actual getting of the Config object happens in
org.eclipse.microprofile.config.spi.ConfigProviderresolver
though, so that might make it harder to fix as it's outside of Quarkus
Then I guess that it may be a discovery ordering issue, meaning that in some cases the correct SPI is the first one selected, and in others, you get the wrong one.
Noticing that in most usages of the config object, it could just be assigned as a generic
Config
, rather than aSmallRyeConfig
. There is at least one usage that requiresSmallRyeConfig
, but maybe we could work around that somehow?
I think it won't work because the Config returned by RunningAppConfigResolver
is not fully implemented.
Do you know have a way to provide a reproducer with the exact steps? Thanks!
Then I guess that it may be a discovery ordering issue, meaning that in some cases the correct SPI is the first one selected, and in others, you get the wrong one.
I had a similar thought, but it was hard to debug to determine if this was true or not.
I think it won't work because the Config returned by RunningAppConfigResolver is not fully implemented
That's good to know.
I linked my project on Github in OP, it's fairly simple as is but could make another, even simpler one. Let me know if you want me to do so @radcortez
Thanks. I'll have a look.
Thanks! Do let me know if you need anything, or have any questions!
@GregJohnStewart I'm having some issues reproducing the problem with the instrucitons you provided? Any chance you can write a smaller single module project from a quickstart that reproduces the issue? Thank you!
@radcortez The quarkus project provided in OP is fairly straight forward, but I have prepared a slimmed down app with tests that fail in the same way (on the cucumber-inttest-repo branch):
Just run ./gradlew quarkusIntTest
to get the error
@radcortez where you able to get a chance to look at this one?
The issue is that the Cucumber Quarkus test class is annotated with both @QuarkusIntegrationTest
and @QuarkusTest
because we need to extend CucumberQuarkusTest
.
I believe that with the current state of the extension we don't have support for @QuarkusIntegrationTesT
, and this is not really a configuration issue. The problem just happens to manifest in config due to the mix of both annotations.
Describe the bug
This one is a little bit of a doozy, but it is my impression there might be a bug with how Integration test test instances are stood up and torn down.
I am attempting to enable the Cucumber Quarkiverse plugin to work with the
@QuarkusIntegrationTest
tests, as Cucumber lends itself to integration/ acceptance level testing. I have a client that is trying to use Cucumber and is having to bend over backwards to use the tool, and is currently forced to do a lot of workaround to accommodate.The cucumber extension simply adds tests in a dynamic fashion, letting cucumber handle the individual tests:
This works fine in normal test mode.
I am attempting to enable integration tests by simply extending this class:
Which follows the convention of extending a regular test to make it run as integration.
However, the test Quarkus service can't seem to be run for the cucumber tests, while other integeration tests are unaffected.
Expected behavior
The cucumber tests should run fine in integration mode, when setup to run so.
Actual behavior
With the following configuration:
I get the following error when the test instance is stood up for the cucumber tests:
When I run just the cucumber tests (commenting out all the other integration tests):
How to Reproduce?
The service I am testing this with is here:
https://github.com/Epic-Breakfast-Productions/OpenQuarterMaster/tree/main/software/drivers/open-qm-driver-server
Note you will need to run
./gradlew publishToMavenLocal
on https://github.com/Epic-Breakfast-Productions/OpenQuarterMaster/tree/main/software/libs/open-qm-driver first.Simply run
./gradlew quarkusIntTest
in the driver-server project.Output of
uname -a
orver
Linux gen-dev-box 5.13.0-40-generic #45~20.04.1-Ubuntu SMP Mon Apr 4 09:38:31 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
Output of
java -version
openjdk version "11.0.14.1" 2022-02-08 OpenJDK Runtime Environment (build 11.0.14.1+1-Ubuntu-0ubuntu1.20.04) OpenJDK 64-Bit Server VM (build 11.0.14.1+1-Ubuntu-0ubuntu1.20.04, mixed mode, sharing)
GraalVM version (if different from Java)
No response
Quarkus version or git rev
2.8.1.Final
Build tool (ie. output of
mvnw --version
orgradlew --version
)------------------------------------------------------------ Gradle 7.3.3 ------------------------------------------------------------ Build time: 2021-12-22 12:37:54 UTC Revision: 6f556c80f945dc54b50e0be633da6c62dbe8dc71 Kotlin: 1.5.31 Groovy: 3.0.9 Ant: Apache Ant(TM) version 1.10.11 compiled on July 10 2021 JVM: 11.0.14.1 (Ubuntu 11.0.14.1+1-Ubuntu-0ubuntu1.20.04) OS: Linux 5.13.0-40-generic amd64
Additional information
I am putting this issue out here (the main Quarkus repo) as the actual extension git doesn't have a ton of visibility, and based on my digging appears that the issue most likely lies on the Quarkus side rather than the extension's. Supporting this theory is the startup seems to fail before the
getTests
even run.