stork-kubernetes-quickstart is failing with the latest Quarkus main

[rsvoboda]

stork-kubernetes-quickstart is failing with the latest Quarkus main

https://github.com/quarkusio/quarkus-quickstarts/actions/runs/10397663385/job/28793729373

Caused by: java.lang.NoSuchMethodError: 'io.fabric8.kubernetes.client.ConfigFluent io.fabric8.kubernetes.client.ConfigBuilder.withMasterUrl(java.lang.String)'

Details:

[INFO] -------------------------------------------------------
[INFO]  T E S T S
[INFO] -------------------------------------------------------
[INFO] Running org.acme.FrontendApiResourceTest
2024-08-15 03:14:40,993 INFO  [okh.moc.MockWebServer] (MockWebServer 60193) MockWebServer[60193] starting to accept connections
2024-08-15 03:14:41,617 INFO  [okh.moc.MockWebServer] (MockWebServer 60193) MockWebServer[60193] done accepting connections: Socket closed
Error:  Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 6.601 s <<< FAILURE! -- in org.acme.FrontendApiResourceTest
Error:  org.acme.FrontendApiResourceTest.testApiEndpoint -- Time elapsed: 0.011 s <<< ERROR!
java.lang.RuntimeException: java.lang.RuntimeException: Failed to start quarkus
	at io.quarkus.test.junit.QuarkusTestExtension.throwBootFailureException(QuarkusTestExtension.java:643)
	at io.quarkus.test.junit.QuarkusTestExtension.interceptTestClassConstructor(QuarkusTestExtension.java:727)
	at java.base/java.util.Optional.orElseGet(Optional.java:364)
	at java.base/java.util.ArrayList.forEach(ArrayList.java:1511)
	at java.base/java.util.ArrayList.forEach(ArrayList.java:1511)
Caused by: java.lang.RuntimeException: Failed to start quarkus
	at io.quarkus.runner.ApplicationImpl.doStart(Unknown Source)
	at io.quarkus.runtime.Application.start(Application.java:101)
	at java.base/java.lang.reflect.Method.invoke(Method.java:569)
	at io.quarkus.runner.bootstrap.StartupActionImpl.run(StartupActionImpl.java:305)
	at io.quarkus.test.junit.QuarkusTestExtension.doJavaStart(QuarkusTestExtension.java:248)
	at io.quarkus.test.junit.QuarkusTestExtension.ensureStarted(QuarkusTestExtension.java:610)
	at io.quarkus.test.junit.QuarkusTestExtension.beforeAll(QuarkusTestExtension.java:660)
	... 1 more
Caused by: java.lang.NoSuchMethodError: 'io.fabric8.kubernetes.client.ConfigFluent io.fabric8.kubernetes.client.ConfigBuilder.withMasterUrl(java.lang.String)'
	at io.smallrye.stork.servicediscovery.kubernetes.KubernetesServiceDiscovery.<init>(KubernetesServiceDiscovery.java:85)
	at io.smallrye.stork.servicediscovery.kubernetes.KubernetesServiceDiscoveryProvider.createServiceDiscovery(KubernetesServiceDiscoveryProvider.java:31)
	at io.smallrye.stork.servicediscovery.kubernetes.KubernetesServiceDiscoveryProvider_ClientProxy.createServiceDiscovery(Unknown Source)
	at io.smallrye.stork.servicediscovery.kubernetes.KubernetesServiceDiscoveryProviderLoader.createServiceDiscovery(KubernetesServiceDiscoveryProviderLoader.java:33)
	at io.smallrye.stork.servicediscovery.kubernetes.KubernetesServiceDiscoveryProviderLoader_ClientProxy.createServiceDiscovery(Unknown Source)
	at io.smallrye.stork.Stork.createService(Stork.java:205)
	at io.smallrye.stork.Stork.<init>(Stork.java:127)
	at io.smallrye.stork.Stork.initialize(Stork.java:276)
	at io.quarkus.stork.SmallRyeStorkRecorder.initialize(SmallRyeStorkRecorder.java:27)
	at io.quarkus.deployment.steps.SmallRyeStorkProcessor$initializeStork1271227497.deploy_0(Unknown Source)
	at io.quarkus.deployment.steps.SmallRyeStorkProcessor$initializeStork1271227497.deploy(Unknown Source)
	... 8 more

[rsvoboda]

CC @gsmet @aureamunoz Also @metacosm as you discussed fabric8 during Tuesday call

[rsvoboda]

So it's because of kubernetes-client bump in quarkusio/quarkus#42450

Downgrading kubernetes-client from 6.13.3 back to 6.13.1 makes Stork work again. CC @manusa

[manusa]

This is extremely weird.
I'm off until the 26th, I'll reach out to @metacosm when I'm back to see what he found out.

[metacosm]

CC @gsmet @aureamunoz Also @metacosm as you discussed fabric8 during Tuesday call

Yeah, that's a manifestation of the issue I was discussing on the call except somewhat weirder because this isn't dealing with boxed vs unboxed types… 🤔

[gsmet]

Are you sure it's not a problem with the builder being generated in the Kubernetes Client?

Because it's not even native failing and it looks like the method is simply not around.

[metacosm]

The issue we're seeing happens in JVM mode. Nothing to do with native.

[gsmet]

That's what I wrote :).

My guess is that the new client is just binary incompatible. Maybe the return type has changed slightly (in the binary, the return type is also part of the signature).

My guess is that we just need a new Stork version compiled with 6.13.3.

@aureamunoz you around to do that?

[manusa]

That's the thing, it should be binary compatible from the child class ConfigBuilder.
The problem seems to be that references are kept to the internal parent classes (that no longer exist or contain such methods) to reach their builder methods. But AFAIU this shouldn't be a problem for a regular Java execution. It might be related to the fact that Quarkus moves the processing to build time (but this is a wild guess).

[cescoffier]

Stork does not do anything at build time, this is pure runtime.

[gsmet]

I don't think so. My guess is that it's a pure Java issue and it's really as simple as the signature has changed (for whatever reason).
Binary compatibility can be tricky.

[manusa]

I guess the problem is that 6.13.3 is source compatible but not binary compatible with 6.13.1.
Stork's bytecode might be holding a reference to ConfigFluent and the internal methods there instead of referencing ConfigBuilder itself (this can probably be checked by inspecting the produced byt code of the class that caused the NPE.
Sadly, this means that both dependencies need to be bumped simultaneously.

[cescoffier]

We released a Stork 2.6.1 to workaround the issue.