+1 in general though I think the jira description is misleading somehow. `Stat.version` order assumption, if any, was broken long before it reached `-1`.
By skipping `-1` of `Stat.version` we can maintain version checks in case of overflow. Currently, version check has no effect[1] for `setData`[2] when `Stat.version` reaches `-1`. I think it might be worth documenting the possible overflow of `Stat.version` just like how we document overflow in sequence node naming[3]. "Time in ZooKeeper"[4] is a good place for the documentation, it has a section about `Stat.version`, `Stat.cversion` and `Stat.aversion`. [1]: https://github.com/apache/zookeeper/blob/b31f776471fef79ab161f416d58367bdffaf37a9/zookeeper-server/src/main/java/org/apache/zookeeper/server/PrepRequestProcessor.java#L737 [2]: https://github.com/apache/zookeeper/blob/b31f776471fef79ab161f416d58367bdffaf37a9/zookeeper-server/src/main/java/org/apache/zookeeper/ZooKeeper.java#L2186 [3]: https://zookeeper.apache.org/doc/r3.9.0/zookeeperProgrammers.html#Sequence+Nodes+--+Unique+Naming [4]: https://zookeeper.apache.org/doc/r3.9.0/zookeeperProgrammers.html#sc_timeInZk Best, Kezhu Wang On Fri, Sep 15, 2023 at 10:35 PM tison <wander4...@gmail.com> wrote: > > Hi, > > I'd like to prioritize this issue[1] for pre discussion so that we can > determine whether or not it's a good direction to improve set data with > version experience. > > The title is as email title and please check the JIRA ticket for details. > > Best, > tison. > > [1] https://issues.apache.org/jira/browse/ZOOKEEPER-4743
