[CURATOR-319] NodeCache recreates deleted parents of the node being cached

[jira-importer]

Starting with Curator 2.10.0, the NodeCache will spontaneously re-create parents of the node being cached if one of them is deleted. As an example, if there is a NodeCache watching node /a/b/c and node b is deleted, the cache will immediately recreate node b (but not c) when the change is processed. This seems to stem from this commit: f02fb22

This was not the behavior prior to 2.10.0, and seems pretty unexpected.

---

Originally reported by twbecker, imported from: NodeCache recreates deleted parents of the node being cached

• status: Open
• priority: Major
• resolution: Unresolved
• imported: 2025-01-21

[jira-importer]

randgalt:

This is a larger issue in Curator. Nearly all of the recipes attempt to create parents as needed. I'm not sure what the right thing to do is.

[jira-importer]

dragonsinth:

As a workaround, if you use TreeCache with depth = 0 it won't create any parents.

[jira-importer]

twbecker:

Yeah, I guess it's not entirely straightforward. But in my mind, something labeled a cache should not modify ZK at all. Maybe there could be a mode where an exception is thrown when the cache is started if the node that it's caching isn't there. And then if it subsequently goes away, just returning null for the contents.

[jira-importer]

randgalt:

It's all over Curator. We need some kind of global flag that defines this behavior.

[jira-importer]

dragonsinth:

I actually have to agree with Tommy in principle. It makes sense for most of the recipes to create parent paths when needed, but I really can't think of a good reason for anything in the recipes.cache package to modify ZK at all. I don't know why we added a createParents option to TreeCache.

[jira-importer]

randgalt:

It was to make it like the other recipes - consistency. I'm OK with doing a major version bump that changes the behavior or makes it optional, etc.

[jira-importer]

dragonsinth:

I understand in the past there may have been an issue with leaking 'exist' watches set for nodes that don't exist on the server? I think that all the work that's gone into restructuring client-side watches in Curator, combined with the addition of the ZK removeWatches should allow handling that issue?