JSON deserialization problem when watch `V1Pod` events with `bookmark` enabled.

[dongxinEric]

Describe the bug
We encountered the same problem first reported here: deserialization exception was thrown when iterating the Watchable<V1Pod> because the bookmark events do not have fully constructed V1Pod object in the payload.

Client Version
24.0.0

Kubernetes Version
1.33.2-gke.1111000

Java Version
Java 24

To Reproduce
Steps to reproduce the behavior:

(borrowing from first report of the bug)

try (Watch<V1Pod> watch = Watch.createWatch(client, api.listNamespacedPod("namespace")
        .timeoutSeconds(60)
        .watch(true)
        .allowWatchBookmarks(true)
        .resourceVersion(currentVersion)
        .buildCall(null), (new TypeToken<Watch.Response<V1Pod>>() {
}).getType())) {
    for (Watch.Response<V1Pod> response : watch) {
        //do something with the response
    }
}

Expected behavior
Iterating through the response should not throw the following deserialization exception

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)
...

KubeConfig
N/A

Server (please complete the following information):

• OS: RockyLinux
• Environment: Docker
• Cloud: GCP

Additional context

[brendandburns]

fwiw, I believe that this is because containers is of type list in the OpenAPI spec and null lists (as opposed to empty lists) aren't supported.

I think that this requires that the Kubernetes OpenAPI specification be updated (or the client generator is updated to be tolerant of null lists being empty lists.)

[dongxinEric]

Thank you @brendandburns for taking a look. Please keep us posted!

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale