Skip to main content
← Back to list
01Issue
BugShippedSwamp CLIPublic
Assigneeshammz

Relationships

#2126 Brief local model-lock contention incurs a roughly one-second initial retry delay

Opened by hammz · 9/13/2026· Shipped 9/15/2026

Description

A local model-lock acquisition that briefly encounters a live holder inherits a 1,000 ms initial retry interval. Even if the holder releases shortly afterward, the waiter does not attempt acquisition again until its jittered delay expires.

Reproduction scenario

  1. Use a local filesystem datastore and two callers targeting the same model lock.
  2. Let the first caller hold the lock while the second caller attempts acquisition.
  3. Release the first lock shortly after that failed acquisition attempt, well before one second.
  4. Inspect the waiter's retry scheduling before its next acquisition attempt.

Actual behavior

createModelLock() in src/cli/repo_context.ts constructs FileLock with lockKey and maxWaitMs, without overriding retryIntervalMs.

In src/infrastructure/persistence/file_lock.ts, the default retry interval is 1,000 ms. acquire() starts its backoff at that interval and applies jitter with factor 0.25, so its first scheduled contention delay is approximately 750-1,250 ms when sufficient timeout budget remains. Backoff then doubles up to the existing cap. A release during the initial sleep does not wake the waiter, adding avoidable latency to brief local lock handoffs, including resumed workflow steps.

Expected behavior

Brief local model-lock contention permits a prompt retry after release, while sustained contention still uses bounded backoff and respects the acquisition timeout.

Suggested fix direction

Set a shorter initial retry interval for local model locks, such as 25 ms, through the existing FileLock option. Retain jitter, exponential backoff, timeout, ownership, heartbeat, and stale-lock behavior. Keep this scoped to local model locks rather than changing custom datastore lock policies.

Measurement limitation

The delay mechanism and range above are code-derived. The proposed 25 ms interval is a candidate, and its improvement has not been benchmarked.

Evidence and scope

Inspected swamp core source at revision 7b111963. The reproduction scenario and actual behavior below are derived from source inspection; no released binary or end-to-end reproduction was tested for this report.

02Bog Flow
OPENTRIAGEDIN PROGRESSSHIPPED+ 2 MORETRIAGE+ 6 MOREREVIEW+ 10 MOREPR_MERGED+ 2 MORESESSION_SUMMARIZED

Shipped

9/15/2026, 10:50:25 PM

Click a lifecycle step above to view its details.

03Sludge Pulse
hammz assigned hammz9/15/2026, 9:49:29 PM

Sign in to post a ripple.