Error java.lang.IllegalArgumentException: Expected the field `containers` to be an array in the JSON string but got `null`

[timsmelik]

Describe the bug After upgrading from 19.0.0 to 20.0.0 we encounter the following error:

java.lang.IllegalArgumentException: Expected the field `containers` to be an array in the JSON string but got `null`
    at io.kubernetes.client.openapi.models.V1PodSpec.validateJsonObject(V1PodSpec.java:1354)
    at io.kubernetes.client.openapi.models.V1Pod.validateJsonObject(V1Pod.java:280)
    at io.kubernetes.client.openapi.models.V1Pod$CustomTypeAdapterFactory$1.read(V1Pod.java:309)
    at io.kubernetes.client.openapi.models.V1Pod$CustomTypeAdapterFactory$1.read(V1Pod.java:299)
    at com.google.gson.TypeAdapter$1.read(TypeAdapter.java:204)
    at com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$1.readIntoField(ReflectiveTypeAdapterFactory.java:212)
    at com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$FieldReflectionAdapter.readField(ReflectiveTypeAdapterFactory.java:433)
    at com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$Adapter.read(ReflectiveTypeAdapterFactory.java:393)
    at com.google.gson.Gson.fromJson(Gson.java:1227)
    at com.google.gson.Gson.fromJson(Gson.java:1137)
    at com.google.gson.Gson.fromJson(Gson.java:1047)
    at com.google.gson.Gson.fromJson(Gson.java:1014)
    at io.kubernetes.client.openapi.JSON.deserialize(JSON.java:722)
    at io.kubernetes.client.util.Watch.parseLine(Watch.java:172)
    at io.kubernetes.client.util.Watch.next(Watch.java:128)
    at io.kubernetes.client.util.Watch.next(Watch.java:38)
    at io.kubernetes.client.informer.cache.ReflectorRunnable.watchHandler(ReflectorRunnable.java:234)
    at io.kubernetes.client.informer.cache.ReflectorRunnable.run(ReflectorRunnable.java:137)
    at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
    at java.base/java.util.concurrent.FutureTask.runAndReset(Unknown Source)
    at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown Source)
    at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
    at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
    at java.base/java.lang.Thread.run(Unknown Source)

Client Version 20.0.0

Kubernetes Version 1.27.9

Java Version Java 17

To Reproduce

SharedIndexInformer<V1Pod> podInformer =
        sharedInformerFactory.sharedIndexInformerFor(
            params ->
                coreV1Api
                    .listNamespacedPod("our-namespace")
                    .allowWatchBookmarks(true)
                    .labelSelector("app=our-app)
                    .resourceVersion(params.resourceVersion)
                    .timeoutSeconds(params.timeoutSeconds)
                    .watch(params.watch)
                    .buildCall(null),
            V1Pod.class,
            V1PodList.class);

    podInformer.addEventHandler(eventHandler);

    sharedInformerFactory.startAllRegisteredInformers();

Deploy on a cluster running 1.27.9

Expected behavior No errors

KubeConfig N/A

Server (please complete the following information): Azure AKS

Additional context When manually calling the endpoint from within the pod, we get a valid response: a PodList. Every items[].spec.containers field contains an array of containers, not null. If specifics are needed, let me know. Unfortunately I am not allowed to share the entire response.

[timsmelik]

Just updated to 20.0.1-legacy without issues, but we would still like the non-legacy version to work.

[brendandburns]

This is a duplicate of #3319, see the discussion there.

[brendandburns]

@timsmelik

per the API spec containers is a required field in the PodSpec so it really can't be null. How (or why) are you creating a PodSpec with an empty list of containers?

[timsmelik]

@timsmelik

per the API spec containers is a required field in the PodSpec so it really can't be null. How (or why) are you creating a PodSpec with an empty list of containers?

That's the thing: we're not doing that. As I mentioned in the "Additional context" section, if I manually execute the same call from within the pod that is giving this error, using the same credentials the lib is using in io.kubernetes.client.util.Config, I get a valid response with every item under items containing a spec field which always contains a containers key with an array that holds a single container definition as value.