It is possible to use a constructor that doesn't exist when doing cascading deletion of the custom resource

[serrss]

It is possible to execute the following code
client().customResources(...).withName(null).cascading(true).delete()
which will cause an error io.fabric8.kubernetes.client.KubernetesClientException: An error has occurred.
In this way use a constructor that doesn't exist.

Additional information:
kubernetes-client version v4.0.5

Stacktrace:

io.fabric8.kubernetes.client.KubernetesClientException: An error has occurred. at io.fabric8.kubernetes.client.KubernetesClientException.launderThrowable(KubernetesClientException.java:62) ~[kubernetes-client-3.1.8.jar:?] at io.fabric8.kubernetes.client.KubernetesClientException.launderThrowable(KubernetesClientException.java:53) ~[kubernetes-client-3.1.8.jar:?] at io.fabric8.kubernetes.client.dsl.base.BaseOperation.cascading(BaseOperation.java:301) ~[kubernetes-client-3.1.8.jar:?] at io.fabric8.kubernetes.client.dsl.base.BaseOperation.cascading(BaseOperation.java:70) ~[kubernetes-client-3.1.8.jar:?]

...
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.8.0_161] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:1.8.0_161] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_161] at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_161] at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) ~[junit-4.12.jar:4.12] at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) ~[junit-4.12.jar:4.12] at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) ~[junit-4.12.jar:4.12] at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:33) ~[junit-4.12.jar:4.12]

...

Caused by: java.lang.NoSuchMethodException: io.fabric8.kubernetes.client.dsl.internal.CustomResourceOperationsImpl.<init>(okhttp3.OkHttpClient, io.fabric8.kubernetes.client.Config, java.lang.String, java.lang.String, java.lang.String, java.lang.Boolean, io.strimzi.api.kafka.model.KafkaTopic, java.lang.String, java.lang.Boolean, long, java.util.Map, java.util.Map, java.util.Map, java.util.Map, java.util.Map) at java.lang.Class.getConstructor0(Class.java:3082) ~[?:1.8.0_161] at java.lang.Class.getConstructor(Class.java:1825) ~[?:1.8.0_161] at io.fabric8.kubernetes.client.dsl.base.BaseOperation.cascading(BaseOperation.java:298) ~[kubernetes-client-3.1.8.jar:?]

[ljnelson]

Curious if this and #1099 are reporting the same thing? If so it looks like #1124 was supposed to fix this.

[serrss]

@ljnelson I can reproduce it for kubernetes-client version v4.0.5 that already has #1124 so I can't say that my issue with cascading deletion was fixed. Maybe we need to have the same fix as in #1124 but for Cascading?

[ppietruch]

@ljnelson I observe exactly the same issue in my code. Upgrade to v4.0.5 does not help.

[bfink13]

This issue is preventing CustomResource objects from being deleted because they end up with the orphan finalizer. It would appear setting .cascading(true) would prevent that from happening.