🐛 fake: set deletionTimestamp on object passed to Delete - #3558
Conversation
When Delete soft-deletes due to finalizers, reflect deletionTimestamp onto the caller's object like Create/Update/Get already do.
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: dpacgdm 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 |
|
Welcome @dpacgdm! |
|
Hi @dpacgdm. Thanks for your PR. I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with Regular contributors should join the org to skip this step. Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. DetailsInstructions 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-sigs/prow repository. |
alvaroaleman
left a comment
There was a problem hiding this comment.
/hold
Fake client should not do something the actual client doesn't do. We will have to make any change to this for the two in tandem. Its unclear if this is fixable because if the object is gone from storage, the apiserver doesn't return it in the response body
|
More context here: #3098 |
Summary
Client.Deletesoft-deletes an object because finalizers remain, copydeletionTimestamponto the caller's object (same pattern as Create/Update/Get).MergeFrompreserves the timestamp now present on the deleted object.This addresses the fake client half of #3059. The issue was later broadened to also cover the real typed client (
.Error()vs.Into(obj)); that part is out of scope here and can land as a follow-up (see previously stalled #3098).Test plan
go test ./pkg/client/fake/