Change:
listMapping := map[schema.GroupVersionResource]string{ {Group: "group", Version: "version", Resource: "theresource"}: "TheKindList", } <del> infos := []*resource.Info{ { Mapping: &meta.RESTMapping{ Resource: schema.GroupVersionResource{Group: "group", Version: "version", Resource: "theresource"}, }, Name:      "name-foo", Namespace: "ns-foo", }, } </del> <ins> infos := []*resource.Info{} </ins> fakeClient := dynamicfakeclient.NewSimpleDynamicClientWithCustomListKinds(scheme, listMapping) o := &WaitOptions{

Discussion:
What happened: given an empty namespace (no pods), if running: , kubectl errors with the message . What you expected to happen: kubectl should exit with status 0, since the condition to wait for is for all pods to be deleted, and that condition is already satisfied. How to reproduce it (as minimally and precisely as possible): run the example kubectl command Anything else we need to know?: Environment: Kubernetes version (use ): Taking the liberty of skipping other version information, since this is (I assume) purely a client-side bug
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig cli
Seems like didn't fix it correctly: Test in this PR always passed because the always return nil error and visitCount == 1, and the type conversion always fail here:
thanks for the quick fix!
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-contributor-experience at . /lifecycle stale
/remove-lifecycle stale - still an issue, I believe the PR is waiting for re-review
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-contributor-experience at . /lifecycle rotten
/remove-lifecycle rotten

One use-case of is to wait for a lot of resources that you have just deleted. Unfortunately, this workflow is racy because will fail when encountering a resource that doesn't exist (yes, it's probably already gone). I suspect we should just consider 404 resources to be already gone and integrate that condition as part of the normal flow. /sig cli /kind bug
/assign
Duplicate of ?
yes, I tried to add in in But that PR seems not complete.
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
The PR merged, I think we're good now!

Hi. A similar issue was reported here: but the bot had closed it due to inactivity. So, creating a new one with details again. I am facing the same problem on my end. If a resource does not exist or is deleted, but you are using wait --for condition delete, it fails. There is a flag in delete to avoid such errors. A similar condition of flag must be in as well so that it does not fail with errors like below. Thanks.
/sig cli
/assign
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale
Sorry I forget to do this, I'll try to submit a PR this week.
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale
Yes, this would be nice to have.
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-contributor-experience at . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-contributor-experience at .

/lifecycle rotten
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-contributor-experience at . /close
Closing this issue. <detailsIn response to : Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . /close Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Any chance this can be revisited? Thanks!