I'm working on understanding delta_fifo.go in depth from the client-go project. I'm looking at a situation where maybe reports of resource deletions might get dropped.
I'm 98% biased in favor of my own failing to read the code properly, but it seems to me that Delete() will skip a deletion if it doesn't find an appropriate "event queue" (my term for Deltas), and Pop() will remove an event queue that it is processing, even if, say, the last event in the queue is an addition, update or synchronization.
Suppose you begin with an empty set of event queues (an empty queue and empty items) and then you get the following and only the following:
Add() call, which eventually sets up or appends to an event queue,Pop() call which pops it off and chews it up, and thenDelete() call.Won't Delete() skip broadcasting the deletion, since the relevant event queue no longer exists? So since queueActionLocked() won't be called in this case, then doesn't it follow that any downstream ResourceEventListeners will never be notified of this deletion?
Relatively stable links to code in question:
Delete: https://github.com/kubernetes/kubernetes/blob/v1.9.0/staging/src/k8s.io/client-go/tools/cache/delta_fifo.go#L201-L205Pop: https://github.com/kubernetes/kubernetes/blob/v1.9.0/staging/src/k8s.io/client-go/tools/cache/delta_fifo.go#L440-L450Any help greatly appreciated; thanks!
The path you highlighted in Delete() is only called when knownObjects is nil. The documentation for that option indicates it is used to determine what objects the consumer of the queue is aware of and if nil, indicates the consumer does not care about detecting all deletions