Tests start before DevContainer startup

[DFMichelangelo]

Describe the bug

Hi Quarkus fans,
I'm experiencing an issue which I don't understand whether it's a bug or a wrong usage of quarkus.

In my MRE I am using quarkus with reactive & non-blocking IO features.
When I run the tests, I use a postgres devcontainer that runs an import.sql on startup.

Running the import.SQL programmatically using a startup listener does not solve the issue.

Thank you for your help in advance

Expected behavior

I would expect that when running the tests, the database should be ready with the import.sql already run.

Actual behavior

When tests are run, one of the tests fail randomly as the data of import.sql is not loaded in the database. Apparently tests run before the import.sql is run, but I could be wrong.

In my tests, one user retrieved at the beginning of a test is NULL(line 280 of the github action linked above), it shouldn't be. If I run the tests multiple times, other tests fail in the same way

How to Reproduce?

The MRE is available at this Github link, whereas the issue can be viewed here: Github Action.
You can download the repository and run ./gradlew clean test to reproduce the issue.
Tests appear to be flaky since sometimes the database table Users is empty.

Output of uname -a or ver

Linux fedora 6.11.10-300.fc41.x86_64 #1 SMP PREEMPT_DYNAMIC Sat Nov 23 00:51:20 UTC 2024 x86_64 GNU/Linux

Output of java -version

openjdk version "22.0.2" 2024-07-16 OpenJDK Runtime Environment (build 22.0.2+9-70) OpenJDK 64-Bit Server VM (build 22.0.2+9-70, mixed mode, sharing)

Quarkus version or git rev

3.17.4

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

---

Gradle 8.9

Build time: 2024-07-11 14:37:41 UTC
Revision: d536ef36a19186ccc596d8817123e5445f30fef8

Kotlin: 1.9.23
Groovy: 3.0.21
Ant: Apache Ant(TM) version 1.10.13 compiled on January 4 2023
Launcher JVM: 22.0.2 (Oracle Corporation 22.0.2+9-70)
Daemon JVM: /home/dfmic/.jdks/openjdk-22.0.2 (no JDK specified, using current Java home)
OS: Linux 6.11.10-300.fc41.x86_64 amd64

Additional information

Maybe it is supposed to use test/dev containers differently and this is just improper use.

[geoand]

Thanks for reporting!

When tests are run, one of the tests fail randomly as the data of import.sql is not loaded in the database. Apparently tests run before the import.sql is run, but I could be wrong.

How do you come to this conclusion from running the tests? Asking because I ran the sample (which does indeed fail), but I don't see any obvious indication that import.sql was not executed in the proper time

[DFMichelangelo]

How do you come to this conclusion from running the tests? Asking because I ran the sample (which does indeed fail), but I don't see any obvious indication that import.sql was not executed in the proper time

Hi @geoand , thank you for having a look at my issue!
Mine is just a genuine guess, but it's more a perception rather than being based on facts: matter is that since the test is flaky, it's a challenge to "catch" the right steps that reproduce the issue by changing the test itself.

If it's not related to the import.sql (which means, we assume it's correctly loaded), what else could be?
Also, it's interesting to note that some tests pass, whereas some others don't

[gsmet]

I dunno, I had a look at your log output and I can see the import.sql being executed there.