[Bug] [Master] Master failover lock path mismatch between getLock and releaseLock

[wcmolin]

Search before asking

• I had searched in the issues and found no similar issues.

What happened

In FailoverCoordinator.doMasterFailover(), the lock path used by getLock and releaseLock is inconsistent:

// getLock uses a per-master-address lock path
registryClient.getLock(RegistryUtils.getMasterFailoverLockPath(masterAddress));

try {
    // ... failover logic
} finally {
    // releaseLock uses the global enum path, which differs from getLock
    registryClient.releaseLock(RegistryNodeType.MASTER_FAILOVER_LOCK.getRegistryPath());
}

What you expected to happen

getLock and releaseLock should use the same lock path to ensure the lock is properly acquired and released.

Root cause

This issue was introduced by PR #16953 (commit b6b04617). That PR changed getLock from the global lock path RegistryNodeType.MASTER_FAILOVER_LOCK.getRegistryPath() to a per-master-address fine-grained lock path RegistryUtils.getMasterFailoverLockPath(masterAddress), but missed updating the corresponding releaseLock call in the finally block.

Suggested fix

Extract the lock path into a local variable to ensure getLock and releaseLock use the same path:

final String masterFailoverLockPath = RegistryUtils.getMasterFailoverLockPath(masterAddress);
registryClient.getLock(masterFailoverLockPath);
try {
    // ... failover logic
} finally {
    registryClient.releaseLock(masterFailoverLockPath);
}

How to reproduce

Triggered when a Master node undergoes failover.

Version

3.4.1-release / dev

Are you willing to submit PR?

• Yes I am willing to submit a PR!

Code of Conduct

• I agree to follow this project's Code of Conduct.

[SbloodyS]

cc @ruanwenjun

[ruanwenjun]

Yes, this is a bug!

[ruanwenjun]

It's better to modify the method getLock to return a closable lock holder, then we can use try-with-resource to auto release the lock.

[wcmolin]

Good idea! @ruanwenjun Could you help fix this?

[ruanwenjun]

@wcmolin I can fix this.