#2591 s3-datastore: S3Lock.acquire overshoots maxWaitMs by up to a full backoff interval

Defect

S3Lock.acquire can wait well past maxWaitMs before throwing LockTimeoutError. The deadline is only checked at the top of each loop iteration, and the backoff sleep between attempts (up to maxRetryIntervalMs, 8s by default) is not capped to the time remaining.

Evidence

Reproduced while triaging swamp-club#2553 against MinIO, @swamp/s3-datastore 2026.09.24.1, two concurrent swamp model method run calls on the same model:

• SWAMP_LOCK_TIMEOUT_MS=3000: the losing run reported timed out after 6484ms.
• Default 60s: timed out after 63732ms (the reporter on #2553 saw 60.7 to 65.6s).
• The filesystem datastore lock under the same test stops at 3001ms.

Where

datastore/s3/extensions/datastores/_lib/s3_lock.ts, acquire(): the elapsed >= this.maxWaitMs check at the top of the while (true) loop, followed later by the backoff sleep. gcs_lock.ts has the same shape and is likely affected too.

Expected

The wait never exceeds maxWaitMs by more than one in-flight request: cap each backoff sleep at the remaining deadline and check the deadline again before the next attempt. Worth adding to the lock conformance suite so every datastore lock is held to it.

Upstream repository: https://github.com/systeminit/swamp-extensions

Environment

• Extension: @swamp/s3-datastore@2026.09.24.1
• swamp: 20260928.150833.0-sha.6858940b
• OS: linux (x86_64)
• Deno: 2.9.7
• Shell: /usr/bin/zsh