Per-lock timeout
How long a lock is held before it expires is now a parameter on the lock rather than something each implementation hardcodes. It describes the critical section, so the caller decides.
try await lock.withLock("a-long-running-job", timeout: .seconds(600)) {
// operations that should be protected by the lock
}Breaking
DistributedLock conformers must add the parameter to their two methods:
lock(key:logger:)→lock(key:timeout:logger:)unlock(key:startedAt:logger:)→unlock(key:startedAt:timeout:logger:)
unlock receives the timeout so an implementation can tell whether its lock has since expired and may now belong to another holder.
Callers are unaffected. withLock takes timeout: Duration = Self.defaultTimeout, and extensions supply lock(key:logger:) and unlock(key:startedAt:logger:) using defaultTimeout — .seconds(30), the value implementations used to hardcode.
Released as 0.1.0 rather than 0.0.4 so from: "0.0.3" consumers do not pick this up without an explicit bump.
Full changelog: 0.0.3...0.1.0