Currently if a lock is held by someone and you try to perform a blocking acquire, its possible for ETCD to return a 401 (etcd.EtcdEventIndexCleared) when more than 1000 events have occurred since the key was modified. This gets caught here https://github.com/jplana/python-etcd/blob/master/src/etcd/lock.py#L130 and another watch call is made with the same arguments which will again fail leaving it in a while True loop of repeated calls that fail.
Coverage increased (+0.2%) to 88.302% when pulling be74cd16582118757b8f6ccf245768b96bb4a79a on ellipses:fix/blocking-lock into b227f496c038b2b856c4d76c9525b3547e5c8dc4 on jplana:master.
Hi!
Sorry for commenting on such an old PR, but may I ask why this was closed without merge?
I'm facing the same problem and it looks like the PR could also solve https://github.com/jplana/python-etcd/issues/254
Currently if a lock is held by someone and you try to perform a blocking acquire, its possible for ETCD to return a 401 (etcd.EtcdEventIndexCleared) when more than 1000 events have occurred since the key was modified. This gets caught here https://github.com/jplana/python-etcd/blob/master/src/etcd/lock.py#L130 and another watch call is made with the same arguments which will again fail leaving it in a
while True
loop of repeated calls that fail.ETCD docs ( https://coreos.com/etcd/docs/latest/v2/api.html#waiting-for-a-change. ) describe how you recover from this situation by performing a get to obtain the current state and starting a watch from etcd-index + 1 .