Change:
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!

Discussion:
return err } visitor := o.ResourceFinder.Do() <del> if visitor, ok := visitor.(*resource.Result); ok && strings.ToLower(o.ForCondition) == "delete" { </del> <ins> isForDelete := strings.ToLower(o.ForCondition) == "delete" if visitor, ok := visitor.(*resource.Result); ok && isForDelete { </ins> visitor.IgnoreErrors(apierrors.IsNotFound) }

if err != nil { return err } <del> if visitCount == 0 { </del> <ins> if visitCount == 0 && !isForDelete { </ins> return errNoMatchingResources } return err

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{

} }) }) <ins> ginkgo.Describe("kubectl wait", func() { ginkgo.It("should ignore not found error with --for=delete", func() { ginkgo.By("calling kubectl wait --for=delete") framework.RunKubectlOrDie(ns, "wait", "--for=delete", "pod/doesnotexist") framework.RunKubectlOrDie(ns, "wait", "--for=delete", "pod", "--selector=app.kubernetes.io/name=noexist") }) }) </ins> }) // Checks whether the output split by line contains the required elements.