Object doesn't get updated after Client.Delete(object)

fakeClient.Delete(obj) doesn't update deletionTimestamp of the obj passed to the function. The bug is in fakeClient.deleteObject, since it gets a new object and updates the new object without rewriting the original object.

Reference: https://github.com/kubernetes-sigs/controller-runtime/blob/v0.19.0/pkg/client/fake/client.go#L1085-L1095

I assume the regular client updates it? (I think I remember that the regular client also doesn't update it, but I'm not sure)

Actually it looks like it doesn't:

controller-runtime/pkg/client/typed_client.go

Line 86 in 8e44a43

Body(deleteOpts.AsDeleteOptions()).

So after someone deletes an object, their in-mem representation doesn't reflect that? That is different from all other methods and very confusing

Yeah. I think I noticed this 1-2 months ago in a unit test. First I thought the fake client is the problem but then I saw that the real client has the same behavior :)

@troy0820

I can take this one if you all don't mind.

/assign @troy0820

I'm wondering if there are comparable cases in client-go and how they are handled there

@troy0820

/unassign @troy0820

I unfortunately do not have the time to commit to work through the PR for this. I am going to unassign myself for anyone who wants to take this.

Yeah. I think I noticed this 1-2 months ago in a unit test. First I thought the fake client is the problem but then I saw that the real client has the same behavior :)

Do we want to change the real client behavior and then map that to the fakeClient?

I'm wondering if there are comparable cases in client-go and how they are handled there

I think knowing ^^ would be good to inform our decision.

Do we get the object with deletionTimestamp back when we do the actual delete call?

I'm wondering if there are comparable cases in client-go and how they are handled there

I think knowing ^^ would be good to inform our decision.

Do we get the object with deletionTimestamp back when we do the actual delete call?

I don't think we do unless I am reading this wrong on the dynamic client which uses the rest.Interface.

https://github.com/kubernetes/client-go/blob/f2030849e1d6d961fa150b9be9560da33e5d00df/dynamic/simple.go#L205-L219

func (c *dynamicResourceClient) Delete(ctx context.Context, name string, opts metav1.DeleteOptions, subresources ...string) error {
	if len(name) == 0 {
		return fmt.Errorf("name is required")
	}
	if err := validateNamespaceWithOptionalName(c.namespace, name); err != nil {
		return err
	}

	result := c.client.client.
		Delete().
		AbsPath(append(c.makeURLSegments(name), subresources...)...).
		Body(&opts).
		Do(ctx)
	return result.Error()
}

Looks like it. Not sure if there either simply is nothing in the response body or if we just don't read it

I think simply modifying typedClient.Delete()

-               Error()
+               Into(obj)

From my testing, If there's a finalizer on the resource then you will get a response including the timestamp, otherwise it gets deleted, and there's no deletion timestamp.

Retitling as this doesn't affect just the fake client:
/retitle Object doesn't get updated after Client.Delete(object)

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

The Kubernetes project currently lacks enough active 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 rotten
Close this issue with /close
Offer to help out with Issue Triage

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

/lifecycle rotten

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

This bot triages 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:

Reopen this issue with /reopen
Mark this issue as fresh with /remove-lifecycle rotten
Offer to help out with Issue Triage

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

/close not-planned

@k8s-triage-robot

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

Details

In response to this:

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

This bot triages 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:

Reopen this issue with /reopen

Mark this issue as fresh with /remove-lifecycle rotten

Offer to help out with Issue Triage

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

/close not-planned

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-sigs/prow repository.

/reopen
/lifecycle frozen

@alvaroaleman

@alvaroaleman: Reopened this issue.

Details

In response to this:

/reopen
/lifecycle frozen

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-sigs/prow repository.

Navigation Menu

Repository navigation

Object doesn't get updated after Client.Delete(object) #3059

9 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Object doesn't get updated after Client.Delete(object) #3059

Description

Activity

sbueringer commented on Jan 7, 2025

alvaroaleman commented on Jan 7, 2025

sbueringer commented on Jan 7, 2025

troy0820 commented on Jan 8, 2025

sbueringer commented on Jan 9, 2025

troy0820 commented on Jan 13, 2025

troy0820 commented on Jan 28, 2025

sbueringer commented on Jan 28, 2025

troy0820 commented on Jan 28, 2025

sbueringer commented on Jan 28, 2025

bigkevmcd commented on Jan 28, 2025

9 remaining items

alvaroaleman commented on Sep 13, 2025

k8s-triage-robot commented on Dec 12, 2025

k8s-triage-robot commented on Jan 11, 2026

k8s-triage-robot commented on Feb 10, 2026

k8s-ci-robot commented on Feb 10, 2026

alvaroaleman commented on Feb 10, 2026

k8s-ci-robot commented on Feb 10, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions