0.1.0

Per-lock timeout

The lock key expiration was hardcoded to 30 seconds, which silently capped the critical section: an operation running longer than that lost its lock while still running, and another holder could acquire it concurrently. unlock detected the overrun and skipped the DEL, so the only symptom was an error log and lost mutual exclusion.

The timeout now comes from the caller per lock, since it describes the critical section rather than the client:

try await lock.withLock("a-long-running-job", timeout: .seconds(600)) {
  // operations that should be protected by the lock
}

Valkey expires keys at whole-second granularity, so the timeout must be at least one second and any sub-second part of it is truncated.

Breaking

• Requires distributed-lock-swift 0.1.0 for the new lock(key:timeout:logger:) and unlock(key:startedAt:timeout:logger:) requirements.
• Those two methods changed signature. Anything calling them directly needs the extra argument; withLock callers and ValkeyLock(client:) are unchanged, and omitting the timeout still gives the 30 seconds this 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