Fix informer initial list items missing kind/apiVersion

[Copilot]

The Kubernetes API omits kind/apiVersion from individual items in list responses (they're set on the list object itself), but includes them in watch events. This caused ReflectorRunnable's initial list phase to produce items with null type metadata, while subsequent watch events would have them populated — an inconsistency that breaks any code relying on these fields being consistently set.

Changes

• ReflectorRunnable: After fetching the initial list, calls new populateTypeMeta() to backfill kind/apiVersion on items that are missing them.
  • Primary strategy: derives item kind by stripping the "List" suffix from the list's kind (e.g. PodList → Pod) and uses the list's apiVersion directly.
  • Fallback: uses ModelMapper.getGroupVersionKindByClass() / preBuiltGetGroupVersionKindByClass() when the list object itself has no type metadata (e.g. in tests).
  • setKind/setApiVersion Method references are cached in the constructor (one-time reflection lookup per ReflectorRunnable instance) to avoid per-call overhead.

// Before: pods from initial list had null kind/apiVersion
informer.addEventHandler(new ResourceEventHandler<V1Pod>() {
    public void onAdd(V1Pod pod) {
        pod.getKind();       // null during initial list, "Pod" on watch events
        pod.getApiVersion(); // null during initial list, "v1" on watch events
    }
});

// After: consistently populated in both phases
pod.getKind();       // "Pod"
pod.getApiVersion(); // "v1"

• ReflectorRunnableTest: Added 4 unit tests covering the primary path, ModelMapper fallback, no-overwrite of existing values, and end-to-end population through the full list flow.
• InformerListTypeMetaTest (e2e): Added an e2e test that starts a real Namespace informer against a cluster, waits for initial sync, and asserts that every item received via onAdd during the initial list phase has kind="Namespace" and apiVersion="v1" populated — validating the fix against an actual Kubernetes cluster.

[brendandburns]

@copilot can you add an e2e tests for this also to validate this works against an actual cluster?

[Copilot]

@copilot can you add an e2e tests for this also to validate this works against an actual cluster?

Added InformerListTypeMetaTest in e2e/src/test/java/io/kubernetes/client/e2e/informer/ (commit 4dced83). The test starts a real Namespace informer against a cluster, waits for initial sync, and asserts that every item received via onAdd has kind="Namespace" and apiVersion="v1" set — exactly the scenario described in the bug.

[brendandburns]

/lgtm
/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: brendandburns, Copilot

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [brendandburns]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment