Title: RedisLockProvider fails to acquire locks during Redis endpoint redistribution

[dineshbalani]

Describe the bug
When using RedisLockProvider with a service discovery system that periodically redistributes Redis endpoints distributed lock acquisition randomly fails with:

RedLockNet.Exceptions.RedisException: The specified endpoint is not defined

The error is intermittent — sometimes lock acquisition succeeds through the endpoint redistribution event, sometimes it fails. Pod restart always resolves the issue temporarily

To Reproduce
Steps to reproduce the behavior:

• Deploy application using UseRedisLocking(connectionString), where Redis endpoints are redistributed dynamically by a service discovery system

• Let the application run until a Redis endpoint redistribution event occurs

• Observe RedLockNet.Exceptions.RedisException thrown from RedisLockProvider.AcquireLock()

• Restart the pod — error resolves immediately

Expected behavior
[RedisLockProvider.AcquireLock()] should validate the connection state before attempting to create a distributed lock. If the cached IConnectionMultiplexer is disconnected (stale), the provider should reconnect before proceeding rather than using a zombie connection that has no valid endpoints registered in RedLock.

Currently AcquireLock() only checks if (_redlockFactory == null) but never validates _multiplexer.IsConnected.
During endpoint redistribution, StackExchange.Redis begins async background reconnection, but AcquireLock() doesn't wait — it attempts to use the still-disconnected multiplexer immediately, causing RedLock to fail with "endpoint not defined".

Additional context
WorkflowCore: 3.14.0
StackExchange.Redis: 2.8.47
.NET: 8.0

[wfcore-manager]

Thanks for the detailed report — this looks real.

AcquireLock only checks whether _redlockFactory is null. It never looks at _multiplexer.IsConnected, so after a Redis endpoint redistribution we can keep using a multiplexer that is mid-reconnect (or already a zombie), and RedLock then throws The specified endpoint is not defined. A pod restart creating a fresh connection matches that.

I'll get a fix in that reconnects or rebuilds the factory when the multiplexer isn't connected, rather than treating a stale factory as healthy.

If you have it handy: standalone vs cluster, and what your service discovery does on redistribution (DNS change, endpoint list swap, etc.). Either way I'll track this here.

[wfcore-manager]

The Redis reconnect fix shipped in 3.20.0: https://www.nuget.org/packages/WorkflowCore/3.20.0

AcquireLock now reconnects when the multiplexer is disconnected (or missing) instead of using a stale RedLock factory. Worth trying 3.20.0 on your Redis-with-service-discovery setup.

[wfcore-manager]

Confirming this remains fixed in 3.20.0+ via #1437 (RedisLockProvider reconnect). Closing as completed.