fix: handle PodGroup CRD tombstone deletion - #1492
Conversation
Signed-off-by: 0YHR0 <97868579@qq.com>
|
Caution The consumer version of Gemini Code Assist on GitHub has been sunset. All code review activity has officially ceased. |
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
|
/retest |
|
@0YHR0: Cannot trigger testing until a trusted user reviews the PR and leaves an DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
What type of PR is this?
/kind bug
What this PR does / why we need it
The PodGroup CRD informer assumed every delete notification contained a direct
CustomResourceDefinitionobject. Kubernetes informers can instead delivercache.DeletedFinalStateUnknowntombstones when the object is no longer present in the local cache, causing the unchecked type assertion to panic.This change moves delete handling into a dedicated helper that:
Regression tests cover direct deletes, tombstone deletes, unexpected objects, and tombstones containing unexpected objects.
Which issue(s) this PR fixes
None.
Special notes for your reviewer
The change only affects the PodGroup CRD informer delete path. Add and update behavior is unchanged.
How was this change tested?
Does this PR introduce a user-facing change?