What does the queue add over just

go func(e runtime.ContainerEventResponse) {
        c.containerEventsChan <- e
}(event)

Neither approach seems to guarantee the order if that is the intent.

If order preservation is important, could also just have a single dequeue go routine which runs when there are items in the queue, like

func (eq *eventQueue) enqueue(c chan<- runtime.ContainerEventResponse, event runtime.ContainerEventResponse) {
	eq.lock.Lock()
	defer eq.lock.Unlock()
	eq.items = append(eq.items, event)
	if len(eq.items) == 1 {
		go func() {
			var event *runtime.ContainerEventResponse
			for {
				eq.lock.Lock()
				if event != nil {
					eq.items = eq.items[1:]
				}
				if len(eq.items) == 0 {
					eq.lock.Unlock()
					return
				}
				event = &eq.items[0]
				eq.lock.Unlock()
				c <- *event
			}
		}()
	}
}

If just generate one event

for {
	eq.lock.Lock()
	// here  len(eq.items)=1 ,event is not nill
	if event != nil {
		//after next  stup len(eq.items) = 0
		eq.items = eq.items[1:]
	}
	
	//here will return len(eq.items)=0 will lost a event
	if len(eq.items) == 0 {
		eq.lock.Unlock()
		return
	}
	event = &eq.items[0]
	eq.lock.Unlock()
	c <- *event
}

how about add a lock in criService struct

	c.mu.lock()
	eq.enqueue(event)
	c.mu.unlock()

to keep event in order
@dmcgowan

This should be looked for a better solution overall rather than just add more locking/queuing. There are already TODOs around the publishing of the events and it is using a channel which a large buffer which is not a good pattern to avoid lost messages. It probably makes more sense to use a queue but to avoid leaking memory if there is no one calling GetContainerEvents the queue should have an expiration if nothing is removing items from the queue. I don't think a quick fix to just add a queue is going to work as it may lead to a memory leak.