[kamilmysliwiec]

PR Checklist

Please check if your PR fulfills the following requirements:

• The commit message follows our guidelines: https://github.com/nestjs/nest/blob/master/CONTRIBUTING.md
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

PR Type

What kind of change does this PR introduce?

• Bugfix
• Feature
• Code style update (formatting, local variables)
• Refactoring (no functional changes, no api changes)
• Build related changes
• CI related changes
• Other... Please describe:

What is the current behavior?

beforeApplicationShutdown() releases a snapshot of the held locks, and each release wakes the acquire() calls waiting for that key. A woken acquire() gets the lock straight away, and that lock is added after the snapshot, so nothing releases it. It keeps renewing after onApplicationShutdown() has closed the store's connection: each renewal fails, and the lock is later reported lost. An acquire() whose store call was in flight when the hook began ends up the same way.

Issue Number: #40

What is the new behavior?

From the start of beforeApplicationShutdown(), Locks grants no new locks:

• acquire() (and the internal tryAcquire()) resolves null without a store call.
• A grant that lands after the hook began goes back to the store, and the call resolves null.
• Callers waiting for a key stop waiting at once, including a wait on a key held by another instance, which would otherwise sleep until its next backoff (up to 1s).
• A grant whose lock the hook had already released, because the shutdown began between the store's answer and acquire() returning, resolves null instead of a released Lock.
• withLock() rejects with LockNotAcquiredError with reason: 'shutdown' and the message Could not acquire the lock "k": the application is shutting down. reason is a new optional constructor argument that defaults to 'taken', so the existing messages are unchanged.

Thanks to @johnnyhuirilef for the report, the reproduction and the closing flag, which this PR builds on. On top of it, this PR wakes the sleeping waiters, returns null for a grant whose lock the hook already released, and adds the reason on LockNotAcquiredError.

Does this PR introduce a breaking change?

• Yes
• No

Other information

A grant that only lands after onApplicationShutdown() has closed the store can't be given back, so that key stays taken for one ttl. Elections and ticks already behave this way at shutdown, and the hook doesn't wait for such grants, so a stalled store doesn't hold up the deploy.

The docs (content/reliability/locks.md, the acquire()/withLock() paragraph, the shutdown paragraph and the errors table) need a follow-up in docs.nestjs.com.