Occationally ClassCastException due Classloading issues in tests with RestClients

[HerrDerb]

Describe the bug

Since a while (maybe 3.11.2?) we experience some occasionally classloading issues during execution of tests. When rerunning the test, they eventually run through as expected. The issue always seem to originate in the generated RestClient. com.acme.shared is a library I am using in this application.

Caused by: java.lang.ClassCastException: class com.acme.shared.models.PositionsInRoom cannot be cast to class com.acme.shared.models.PositionsInRoom (com.acme.shared.models.PositionsInRoom is in unnamed module of loader 'app'; com.acme.shared.models.PositionsInRoom is in unnamed module of loader io.quarkus.bootstrap.classloading.QuarkusClassLoader @62b2885d)
    at com.acme.testclients.RoomApiClient$$QuarkusRestClientInterface.getPositionsInRoom(Unknown Source)
    at com.acme.integrationtests.tests.api.RoomApiTest$GetPositionsInRoom.lambda$getPositionsInRoom_returnsThePosition$0(RoomApiTest.java:1354)

Does this ring any bell?

This might be related to https://github.com/quarkusio/quarkus/issues/41349

How to Reproduce?

As the circumstances are unclear to me, I cannot provide information how to reproduce

Output of java -version

21

Quarkus version or git rev

3.12.2

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

gradle

[gsmet]

Are you mixing different kind of tests that could explain that sometimes the class is loaded from the app class loader?

Because Surefire won't execute the tests in the same order each time so that could maybe explain that sometimes a different order causes the issue.

One thing you could do to validate this theory would be to force the order of execution, first in one way, and then the other way: https://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#runOrder (use alphabetical and then reversealphabetical).

That might help to pinpoint what's problematic (if the randomness is caused by the order of the tests).

[HerrDerb]

Well, there are plain JUnit and QuarkusTests, if that might be a cause. @gsmet I'll give this a try 👍

[quarkus-bot[bot]]

/cc @cescoffier (rest-client)

[HerrDerb]

@gsmet Seems the issue was caused by the usage of CompletableFuture.supplyAsync for which we did not provide a specific executor. Without providing a specific executor, CompletableFuture uses its own defined executor which is either a simple thread spawner or a ForkJoinPool.

What exactly the cause is, I still don't know, as it did work for already over a year without problems. Also ordering the test execution after JUnit and Quarkus tests (both orders natural and reverse) did not help.