Clarification on Store::wait_until_ready() and Watch Resynchronization

[artsiomkaltovich]

Hello,

I've tried to answer this by looking at the source code, but I'm not sure I fully understand it.

The wait_until_ready() method waits for Event::InitDone. However, I don’t see where the store's "ready" state is reset when handling Event::Init.

Does this mean that once the store becomes ready, any future desynchronization won’t change its state? If so, does that make calling wait_until_ready() on child resource stores unnecessary more than one time?

For context: I have two watchers monitoring two types of resources—owners and owned. I need to ensure the correct state of owned objects before processing resynchronization for owner objects.

Thanks!

[clux]

This happens one level above wait_until_ready in

kube/kube-runtime/src/reflector/store.rs

Lines 113 to 130 in defa19f

	watcher::Event::Init => {
	self.buffer = AHashMap::new();
	}
	watcher::Event::InitApply(obj) => {
	let key = obj.to_object_ref(self.dyntype.clone());
	let obj = Arc::new(obj.clone());
	self.buffer.insert(key, obj);
	}
	watcher::Event::InitDone => {
	let mut store = self.store.write();
	// Swap the buffer into the store
	std::mem::swap(&mut *store, &mut self.buffer);
	// Clear the buffer
	// This is preferred over self.buffer.clear(), as clear() will keep the allocated memory for reuse.
	// This way, the old buffer is dropped.
	self.buffer = AHashMap::new();

.

The clearing is basically in done on intermediate buffers in the self.buffer parts, and when a re-list is done (in InitDone) that buffer replaces the active cache in one swap.

Does this mean that once the store becomes ready, any future desynchronization won’t change its state? If so, does that make calling wait_until_ready() on child resource stores unnecessary more than one time?

Yes, and yes. Once a watcher has synchronised (finshed a list/or streaming init) once, it is always considered "ready". This is because the active cache is still available for querying during a desync. During a desync, we are building up a new self.buffer that will update it once relists completes, but it doesn't impact availability of the store (which is what the ready check is there to gate on).

You shouldn't normally have to think about relists in user code. You might need to explain a bit more if you actually do.