Flaky JWT test

[FroMage]

Describe the bug

I've seen this in the CI logs sometimes:

2025-06-14T18:27:43.0039635Z [INFO] Running io.quarkus.jwt.test.dev.SmallryeJwtPersistentDevModeEncryptedTest
2025-06-14T18:27:43.3156126Z 2025-06-14 18:27:43,260 INFO  [io.qua.sma.jwt.dep.SmallryeJwtDevModeProcessor] (build-13) The smallrye-jwt extension has configured an in-memory key pair, which is not enabled in production. Please ensure the correct keys/locations are set in production to avoid potential issues.
2025-06-14T18:27:43.4142435Z 2025-06-14 18:27:43,336 WARN  [io.qua.arc.pro.BeanArchives] (build-25) Failed to index io.quarkus.jwt.test.dev.SmallryeJwtPersistentDevModeSignedTest: Class does not exist in ClassLoader QuarkusClassLoader:Deployment Class Loader: TEST for SmallryeJwtPersistentDevModeEncryptedTest (QuarkusUnitTest)@654ece96
2025-06-14T18:27:43.4146403Z 2025-06-14 18:27:43,337 INFO  [io.qua.sma.jwt.dep.SmallryeJwtDevModeProcessor] (build-13) Generating private/public keys for DEV/TEST in /home/runner/_work/quarkus/quarkus/extensions/smallrye-jwt/deployment/target/classes/dev.privateKey.pem and /home/runner/_work/quarkus/quarkus/extensions/smallrye-jwt/deployment/target/classes/dev.publicKey.pem
2025-06-14T18:27:43.9458261Z 2025-06-14 18:27:43,938 INFO  [io.quarkus] (main) quarkus-smallrye-jwt-deployment 999-SNAPSHOT on JVM (powered by Quarkus 999-SNAPSHOT) started in 0.432s. Listening on: http://localhost:8081
2025-06-14T18:27:43.9459528Z 2025-06-14 18:27:43,938 INFO  [io.quarkus] (main) Profile test activated. 
2025-06-14T18:27:43.9460532Z 2025-06-14 18:27:43,938 INFO  [io.quarkus] (main) Installed features: [cdi, dummy, reactive-routes, rest, rest-jsonb, security, security-properties-file, smallrye-context-propagation, smallrye-jwt, vertx]
2025-06-14T18:27:44.7161798Z 2025-06-14 18:27:44,709 INFO  [io.quarkus] (main) quarkus-smallrye-jwt-deployment stopped in 0.013s
2025-06-14T18:27:44.7209442Z [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.713 s -- in io.quarkus.jwt.test.dev.SmallryeJwtPersistentDevModeEncryptedTest
2025-06-14T18:27:44.8484110Z [INFO] 
2025-06-14T18:27:44.8484474Z [INFO] Results:
2025-06-14T18:27:44.8484756Z [INFO] 
2025-06-14T18:27:44.8485004Z [ERROR] Errors: 
2025-06-14T18:27:44.8489533Z [ERROR]   SmallryeJwtPersistentDevModeEncryptedTest » Runtime io.quarkus.builder.BuildException: Build failure: Build failed due to errors
2025-06-14T18:27:44.8491397Z 	[error]: Build step io.quarkus.deployment.steps.CompiledJavaVersionBuildStep#compiledJavaVersion threw an exception: java.io.UncheckedIOException: java.nio.file.NoSuchFileException: /home/runner/_work/quarkus/quarkus/extensions/smallrye-jwt/deployment/target/classes/dev.publicKey.pem
2025-06-14T18:27:44.8493084Z 	at java.base/java.nio.file.FileTreeIterator.fetchNextIfNeeded(FileTreeIterator.java:87)
2025-06-14T18:27:44.8493818Z 	at java.base/java.nio.file.FileTreeIterator.hasNext(FileTreeIterator.java:103)
2025-06-14T18:27:44.8494577Z 	at java.base/java.util.Spliterators$IteratorSpliterator.tryAdvance(Spliterators.java:1855)
2025-06-14T18:27:44.8495739Z 	at java.base/java.util.stream.StreamSpliterators$WrappingSpliterator.lambda$initPartialTraversalState$0(StreamSpliterators.java:292)
2025-06-14T18:27:44.8496847Z 	at java.base/java.util.stream.StreamSpliterators$AbstractWrappingSpliterator.fillBuffer(StreamSpliterators.java:206)
2025-06-14T18:27:44.8497852Z 	at java.base/java.util.stream.StreamSpliterators$AbstractWrappingSpliterator.doAdvance(StreamSpliterators.java:169)
2025-06-14T18:27:44.8498920Z 	at java.base/java.util.stream.StreamSpliterators$WrappingSpliterator.tryAdvance(StreamSpliterators.java:298)
2025-06-14T18:27:44.8499859Z 	at java.base/java.util.Spliterators$1Adapter.hasNext(Spliterators.java:681)
2025-06-14T18:27:44.8500334Z 	at io.quarkus.paths.PathTreeVisit.walk(PathTreeVisit.java:21)
2025-06-14T18:27:44.8500731Z 	at io.quarkus.paths.OpenContainerPathTree.walk(OpenContainerPathTree.java:105)
2025-06-14T18:27:44.8501307Z 	at io.quarkus.deployment.steps.CompiledJavaVersionBuildStep.getMajorJavaVersion(CompiledJavaVersionBuildStep.java:48)
2025-06-14T18:27:44.8502039Z 	at io.quarkus.deployment.steps.CompiledJavaVersionBuildStep.compiledJavaVersion(CompiledJavaVersionBuildStep.java:28)
2025-06-14T18:27:44.8502640Z 	at java.base/java.lang.invoke.MethodHandle.invokeWithArguments(MethodHandle.java:732)
2025-06-14T18:27:44.8503079Z 	at io.quarkus.deployment.ExtensionLoader$3.execute(ExtensionLoader.java:856)
2025-06-14T18:27:44.8503560Z 	at io.quarkus.builder.BuildContext.run(BuildContext.java:255)
2025-06-14T18:27:44.8503927Z 	at org.jboss.threads.ContextHandler$1.runWith(ContextHandler.java:18)
2025-06-14T18:27:44.8504470Z 	at org.jboss.threads.EnhancedQueueExecutor$Task.doRunWith(EnhancedQueueExecutor.java:2651)
2025-06-14T18:27:44.8504965Z 	at org.jboss.threads.EnhancedQueueExecutor$Task.run(EnhancedQueueExecutor.java:2630)
2025-06-14T18:27:44.8505451Z 	at org.jboss.threads.EnhancedQueueExecutor.runThreadBody(EnhancedQueueExecutor.java:1622)
2025-06-14T18:27:44.8506285Z 	at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1589)
2025-06-14T18:27:44.8506717Z 	at java.base/java.lang.Thread.run(Thread.java:840)
2025-06-14T18:27:44.8507038Z 	at org.jboss.threads.JBossThread.run(JBossThread.java:501)
2025-06-14T18:27:44.8507613Z Caused by: java.nio.file.NoSuchFileException: /home/runner/_work/quarkus/quarkus/extensions/smallrye-jwt/deployment/target/classes/dev.publicKey.pem
2025-06-14T18:27:44.8508276Z 	at java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:92)
2025-06-14T18:27:44.8508743Z 	at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:106)
2025-06-14T18:27:44.8509438Z 	at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111)
2025-06-14T18:27:44.8509922Z 	at java.base/sun.nio.fs.UnixFileAttributeViews$Basic.readAttributes(UnixFileAttributeViews.java:55)
2025-06-14T18:27:44.8510456Z 	at java.base/sun.nio.fs.UnixFileSystemProvider.readAttributes(UnixFileSystemProvider.java:148)
2025-06-14T18:27:44.8510985Z 	at java.base/sun.nio.fs.LinuxFileSystemProvider.readAttributes(LinuxFileSystemProvider.java:99)
2025-06-14T18:27:44.8511423Z 	at java.base/java.nio.file.Files.readAttributes(Files.java:1851)
2025-06-14T18:27:44.8511908Z 	at java.base/java.nio.file.FileTreeWalker.getAttributes(FileTreeWalker.java:220)
2025-06-14T18:27:44.8512558Z 	at java.base/java.nio.file.FileTreeWalker.visit(FileTreeWalker.java:277)
2025-06-14T18:27:44.8513399Z 	at java.base/java.nio.file.FileTreeWalker.next(FileTreeWalker.java:374)
2025-06-14T18:27:44.8514129Z 	at java.base/java.nio.file.FileTreeIterator.fetchNextIfNeeded(FileTreeIterator.java:94)
2025-06-14T18:27:44.8514627Z 	... 21 more

Expected behavior

No response

Actual behavior

No response

How to Reproduce?

No response

Output of uname -a or ver

No response

Output of java -version

No response

Quarkus version or git rev

No response

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

No response

Additional information

No response

[quarkus-bot]

/cc @sberyozkin (jwt)

[sberyozkin]

Thanks @FroMage for creating a tracker, looks like a timing issue

[FroMage]

This is perhaps a question for @aloubyansky : we have two build items that depend on CurateOutcomeBuildItem:

• CompiledJavaVersionBuildStep.compiledJavaVersion which looks at the compiled classes to find the Java version
• SmallryeJwtDevModeProcessor.generateSignKeys which generates keys in DEV mode, and stores them in target/classes (as determined by CurateOutcomeBuildItem) to survive restart.

Apparently, they can be executed in parallel and compiledJavaVersion throws a NoSuchFileException for some reason, perhaps before generateSignKeys is done generating the file?

It's rather annoying this exception, because compiledJavaVersion does not care at all about these generated files. But it doesn't appear to be able to walk the file tree without this exception being generated.

I'd perhaps introduce a build item to order them, but I suspect we'll have other tree traversal issues somewhere else.

Any idea how I can solve this?

[aloubyansky]

That's an interesting one. We could probably persist the keys when we stop the app.
Otherwise, another build item seems to make sense. If there are other build steps adding content to the classes directories, perhaps some general generated-persistent-resource build item could be introduced.