Change:
} } } <ins> func Test_dropEndpointSlicesPendingDeletion(t *testing.T) { now := metav1.Now() endpointSlices := []*discovery.EndpointSlice{ { ObjectMeta: metav1.ObjectMeta{ Name:              "epSlice1", DeletionTimestamp: &now, }, }, { ObjectMeta: metav1.ObjectMeta{ Name: "epSlice2", }, AddressType: discovery.AddressTypeIPv4, Endpoints: []discovery.Endpoint{ { Addresses: []string{"172.18.0.2"}, }, }, }, { ObjectMeta: metav1.ObjectMeta{ Name: "epSlice3", }, AddressType: discovery.AddressTypeIPv6, Endpoints: []discovery.Endpoint{ { Addresses: []string{"3001:0da8:75a3:0000:0000:8a2e:0370:7334"}, }, }, }, } epSlice2 := endpointSlices[1] epSlice3 := endpointSlices[2] result := dropEndpointSlicesPendingDeletion(endpointSlices) assert.Len(t, result, 2) for _, epSlice := range result { if epSlice.Name == "epSlice1" { t.Errorf("Expected EndpointSlice marked for deletion to be dropped.") } } // We don't use endpointSlices and instead check manually for equality, because // `dropEndpointSlicesPendingDeletion` mutates the slice it receives, so it's easy // to break this test later. This way, we can be absolutely sure that the result // has exactly what we expect it to. if !reflect.DeepEqual(epSlice2, result[0]) { t.Errorf("EndpointSlice was unexpectedly mutated. Expected: %+v, Mutated: %+v", epSlice2, result[0]) } if !reflect.DeepEqual(epSlice3, result[1]) { t.Errorf("EndpointSlice was unexpectedly mutated. Expected: %+v, Mutated: %+v", epSlice3, result[1]) } } </ins>

Discussion:
As discussed in , Endpoint(Slice) controllers can get stuck if an Endpoints or EndpointSlice resource is stuck in a terminating state. I don't think there's much we can do for Endpoints here since the same name is reused, but EndpointSlice controllers can ignore EndpointSlices in a terminating state. See No response All supported versions Any Any Any Any Any
/sig network
/triage accepted
deleting a service with a finalizer doesn't affect the endpointslice, it doesn't change its status to termination or unready Repro: finalizer to the service and delete it, it keeps waiting until the finalizer is removed with the deletion timestamp set. the endpoint slice associated Do you mean that when the endpoint slice controller detects that the Service is being deleted should switch the endpoint slice status to Terminating? cc:
I don't think we need to do anything special if the Service is waiting to be deleted. There are many legitimate reasons for this to happen, including waiting for infrastructure to be removed. My main concern with a finalizer was that one on an EndpointSlice could cause the controller to get stuck on a Service. We don't have the same risk with a finalizer on a Service - I don't think that would cause the controller to get stuck in any way.
i was unable to repro the issue on my machine: I was monitoring the logs of , and the endpointslice controller never complained about , when I deleted the service. Though, I was able to get the controller to log this error under a different scenario. If we don't explicitly remove the finalizer from the endpointslice, and instead re-create the pod and service like: From what I can understand, because the endpointslice with the finalizer is owned by a service with a different UID than the new endpointslice, it is marked as expected for deletion . The endpointslice controllers calls , which returns true for the endpointslice with the finalizer, because of the above reason. I might be wrong anywhere here, so please let me know if that is the case. As for further action, I'm not sure what can be done here? We could check the endpointslice for finalizers and then skip them . Keen to hear your thoughts about this.