Quarkus OIDC shouldn't fail, when Auth Server is not up

Describe the bug When I start a quarkus application with the oidc extension used, the startup will fail, when the auth server is not reachable.

Expected behavior Application should start normal, maybe with a warning and an automatic retry

Actual behavior Application stops with following exception: java.util.concurrent.CompletionException: io.netty.channel.AbstractChannel$AnnotatedConnectException: Connection refused: localhost/127.0.0.1:8180 at java.base/java.util.concurrent.CompletableFuture.reportJoin(CompletableFuture.java:412) at java.base/java.util.concurrent.CompletableFuture.join(CompletableFuture.java:2044) at io.quarkus.oidc.VertxKeycloakRecorder.setup(VertxKeycloakRecorder.java:59) at io.quarkus.deployment.steps.VertxKeycloakBuildStep$setup28.deploy_0(VertxKeycloakBuildStep$setup28.zig:92) at io.quarkus.deployment.steps.VertxKeycloakBuildStep$setup28.deploy(VertxKeycloakBuildStep$setup28.zig:36) at io.quarkus.runner.ApplicationImpl1.doStart(ApplicationImpl1.zig:137) at io.quarkus.runtime.Application.start(Application.java:94) at io.quarkus.runner.RuntimeRunner.run(RuntimeRunner.java:135) at io.quarkus.dev.DevModeMain.doStart(DevModeMain.java:180) at io.quarkus.dev.DevModeMain.start(DevModeMain.java:94) at io.quarkus.dev.DevModeMain.main(DevModeMain.java:66) Caused by: io.netty.channel.AbstractChannel$AnnotatedConnectException: Connection refused: localhost/127.0.0.1:8180 Caused by: java.net.ConnectException: Connection refused at java.base/sun.nio.ch.SocketChannelImpl.checkConnect(Native Method) at java.base/sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:779) at io.netty.channel.socket.nio.NioSocketChannel.doFinishConnect(NioSocketChannel.java:327) at io.netty.channel.nio.AbstractNioChannel$AbstractNioUnsafe.finishConnect(AbstractNioChannel.java:336) at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:685) at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:632) at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:549) at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:511) at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:918) at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74) at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) at java.base/java.lang.Thread.run(Thread.java:834) 2019-10-16 20:28:40,692 ERROR [io.qua.dev.DevModeMain] (main) Failed to start quarkus: java.lang.RuntimeException: Failed to start quarkus at io.quarkus.runner.ApplicationImpl1.doStart(ApplicationImpl1.zig:185) at io.quarkus.runtime.Application.start(Application.java:94) at io.quarkus.runner.RuntimeRunner.run(RuntimeRunner.java:135) at io.quarkus.dev.DevModeMain.doStart(DevModeMain.java:180) at io.quarkus.dev.DevModeMain.start(DevModeMain.java:94) at io.quarkus.dev.DevModeMain.main(DevModeMain.java:66) Caused by: java.util.concurrent.CompletionException: io.netty.channel.AbstractChannel$AnnotatedConnectException: Connection refused: localhost/127.0.0.1:8180 at java.base/java.util.concurrent.CompletableFuture.reportJoin(CompletableFuture.java:412) at java.base/java.util.concurrent.CompletableFuture.join(CompletableFuture.java:2044) at io.quarkus.oidc.VertxKeycloakRecorder.setup(VertxKeycloakRecorder.java:59) at io.quarkus.deployment.steps.VertxKeycloakBuildStep$setup28.deploy_0(VertxKeycloakBuildStep$setup28.zig:92) at io.quarkus.deployment.steps.VertxKeycloakBuildStep$setup28.deploy(VertxKeycloakBuildStep$setup28.zig:36) at io.quarkus.runner.ApplicationImpl1.doStart(ApplicationImpl1.zig:137) ... 5 more Caused by: io.netty.channel.AbstractChannel$AnnotatedConnectException: Connection refused: localhost/127.0.0.1:8180 Caused by: java.net.ConnectException: Connection refused at java.base/sun.nio.ch.SocketChannelImpl.checkConnect(Native Method) at java.base/sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:779) at io.netty.channel.socket.nio.NioSocketChannel.doFinishConnect(NioSocketChannel.java:327) at io.netty.channel.nio.AbstractNioChannel$AbstractNioUnsafe.finishConnect(AbstractNioChannel.java:336) at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:685) at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:632) at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:549) at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:511) at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:918) at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74) at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) at java.base/java.lang.Thread.run(Thread.java:834)

To Reproduce Steps to reproduce the behavior:

1. Build minimal application
2. Add oicd dependency
3. Add auth server address to application.properties
4. Start server

Configuration

# Add your application.properties here, if applicable.

`quarkus.oidc.auth-server-url=http://localhost:8180/auth/realms/test
quarkus.oidc.client-id=test-client`

[loicmathieu]

@dwalluck normally if you have multiple security providers enabled at the same time it should crash (at build time). As the security layer has been refactored a lot recently it may not still be the case.

With my changes already merged, you can disabled each extension so it fixes your issue but not the one from @UnvirtualHH unfortunatly …

Regarding the issue @UnvirtualHH have, I’m not fan of a connection-retry-interval implementation, it didn’t covers a lot of possible connection issue and seems like a band-aid to me (timeout on socket or on read? which default value? wich max value to avoid stoping all threads during a long time, …).

Two things on my minds:

• Solve your chicken-and-eggs issue properly on your test (using testcontainers for example)
• Make possible the OIDC extension to start without being able to connect to the OIDC server

I think the second is the best as in a container environement we cannot control the order of start of the different containers … and on reliable architecture we cannot make different components depends on each other.

So I sponsor a change to the OIDC extension to make it starts even if it cannot connect to the server.

[sberyozkin]

Hi @loicmathieu - if you have a bit of time then yes, please do it.