kubernetes-client / kubernetes-client/java
LeaderElector fails to acquire expired lease on initial run due to missing expiration check
- Dominant language
- Java
- Stars
- 4k
- Forks
- 2.1k
- Avg merge
- 2d 9h
- Merged PRs (30d)
- 16
Description
**Describe the bug**
There is a flaw in the LeaderElector's tryAcquireOrRenew() logic when handling an existing but expired lease.
On the initial run the application fails to explicitly check if the current observed time has surpassed renewTime + leaseDurationSeconds. Instead, it skips acquiring the lease even when the lock is already free/expired.
**Client Version**
24.0.0
**Kubernetes Version**
1.37.0
**Java Version**
Java 25
**To Reproduce**
Start the test [LeaderElectorExampleTest.java](https://github.com/marbon87/kubernetes-client-java/blob/40d0967c89fd91787ae8c759a89a064cfb62e1f6/extended/src/test/java/io/kubernetes/client/extended/leaderelection/LeaderElectorExampleTest.java) from https://github.com/marbon87/kubernetes-client-java
**Expected behavior**
LeaderElector should acquire a lock on first try without waiting if renewTime + leaseDurationSeconds is in the past.
Possible solution could be https://github.com/kubernetes-client/java/blob/40d0967c89fd91787ae8c759a89a064cfb62e1f6/extended/src/main/java/io/kubernetes/client/extended/leaderelection/LeaderElector.java#L338-L343
**Server (please complete the following information):**
- OS: wsl2 with kind
Contributor guide
Assessment
This issue has not been assessed yet.