lease: fix race condition between KeepAlive and lease expiry

[liyishuai]

Problem

A race condition exists between KeepAlive (Renew) and lease expiry revocation.

When a lease expires, the server's revokeExpiredLeases goroutine proposes a LeaseRevoke through Raft. The apply goroutine then executes Revoke(), which proceeds in two steps:

1. Delete all keys attached to the lease
2. Remove the lease from leaseMap

A concurrent KeepAlive request handled by a separate gRPC goroutine can slip in between these two steps. It finds the lease still in leaseMap and successfully renews it, returning a positive TTL to the client — even though the attached keys are already deleted. The client is misled into believing the lease and its keys are still alive.

The race window is small in practice, but real. The integration test reproduces it deterministically using two gofail failpoints that widen the window.

Fixes #14758

Solution

Close lease.revokec at the start of Revoke(), before releasing the lock to delete keys. In Renew(), after acquiring the lock, check whether revokec is closed. If it is, return ErrLeaseNotFound immediately instead of refreshing the lease.

This ensures any Renew() that races with Revoke() observes the revocation signal and reports the lease as gone, rather than returning a positive TTL with the keys already deleted.

AI Disclosure

AI tools (Claude Opus 4.6 via Claude Code) were used in preparing this PR. This is disclosed per the AI guidance. All changes have been reviewed and verified by the human author.

The prompt used: "Fix etcd issue #14758: a race condition where KeepAlive returns a positive TTL after lease keys have been deleted during revocation. Add an integration test reproducing the race, then implement a fix using the revokec channel to signal revocation early in Revoke() and check it in Renew()."

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: liyishuai
Once this PR has been reviewed and has the lgtm label, please assign spzala for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[k8s-ci-robot]

Hi @liyishuai. Thanks for your PR.

I'm waiting for a etcd-io member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.