Expiration time is in the past

[wombat86]

Version: ^5.0.0-beta.2

When retryCount is greater than 0 it is possible to obtain the lock which is already expired. Check the below snippet:

const lock = await redlock.acquire(['resource'], 1000, {retryCount: 10, retryDelay: 200});
console.log(lock.expiration - Date.now()); // This could be negative in certain cases

Here, if multiple workers/threads/processes are frequently requesting lock for the same resource and hold it for a while, it could lead to a situation when by the time the lock is acquired and returned to the calling code its expiration time is already invalid. With the above code, imagine that the lock is obtained after 1200ms after the beginning of code execution. In this case expiration time would be 200ms in the past.

This issue causes another issue with using(): the lock with expiration in the past causes setTimeout() of the extend() call to trigger immediately (almost :) ) and throw a "Cannot extend an already-expired lock." which is pretty fair since the obtained lock is indeed expired.

[wombat86]

Currently I work this around using my own acquire and using implementations, but I feel that actual fix could be done relatively easily unless there's a purpose behind current logic that I just don't see.

[kotosha-real]

Hi there!

Actually the fix is done, but it was never published. Wrote it all here #299