[askalf]

Fixes the windows-latest / Node 22 CI failure in run 35579991225: 12 concurrent pins all survive failed because one truecopy add exited 1 with EPERM: operation not permitted, open …/race.lock.guard. The other eleven pinned and the lock was correct. (The GitHub Manager card called this a test-runner exit-code mismatch; it is a real, single failing test — 258 pass, 1 fail.)

Cause. acquire() treated only EEXIST as "someone else holds the guard". On Windows, open(wx) on a guard another process is unlinking at that instant returns EPERM (delete-pending). Measured on Windows 11 / Node 22: six processes hammering one guard saw EPERM on ~1% of attempts. With twelve writers that is a near-certain hit per CI run.

Fix. EPERM, EACCES, EBUSY from the guard open are contention: wait and retry like EEXIST, under the same deadline and stale-guard rules. Anything else still throws.

Tests. test/lock-guard-windows.test.mjs: injects each code through the fs module the lock uses and asserts the update lands and the guard is released; an unrelated ENOSPC still fails loudly; six real processes hammer one guard through updateLock and all 240 updates survive. Fails 3/5 against the old code, 5/5 with the fix. Full suite 260 pass, 0 fail (4 skipped as before).

[sprayberry-redline]

Automated review from the Sprayberry Labs fleet code reviewer.
Reviewed by the GPT gating lane (gating review).

Verdict: request changes — a permanent access-denied error can now loop indefinitely instead of failing.

Blocking — correctness — src/lock.mjs:105,119

const GUARD_CONTENTION = new Set(['EEXIST', 'EPERM', 'EACCES', 'EBUSY']);

if (!GUARD_CONTENTION.has(e.code)) throw e;

EACCES (and some EPERM cases) also represents a permanent ACL/parent-directory denial, not a delete-pending guard. For example, if the lock directory is not accessible, openSync(g, 'wx') throws EACCES; guardAge(g) then cannot stat the guard and returns null. The existing if (age === null) continue path is reached before the deadline check, so this newly classified error spins forever rather than reporting the permission failure (or even timing out). That can hang every CLI operation attempting to update a lock on an inaccessible path.

// Treat only a raced-away guard as retryable. Preserve stat/access failures.
try {
  const age = Date.now() - fs.statSync(g).mtimeMs;
  // apply stale/deadline handling to `age`
} catch (statError) {
  if (statError.code === 'ENOENT') continue;
  throw statError;
}

The focused injected-code coverage and the green cross-platform CI matrix are good evidence for the intended Windows contention case, but add a persistent permission-denial regression case when narrowing the retry condition.

[sprayberry-redline]

Automated review from the Sprayberry Labs fleet code reviewer.

Reviewed by the GPT gating lane (gating review).

Verdict: request changes — the new EACCES/EPERM contention handling can still spin forever on a permanent access denial.

• Blocking — src/lock.mjs:155

  } else if (age > staleMs) { try { fs.unlinkSync(g); } catch {} continue; }

  A process can receive EACCES from openSync(g, 'wx'), yet still be allowed to stat an existing stale guard (directory ACLs commonly permit metadata reads while denying deletion). Once that guard exceeds staleMs, a failed unlinkSync is swallowed and the unconditional continue bypasses the timedOut check at line 156 and sleepSync at line 157. The result is a tight, unbounded loop rather than the promised original access error after waitMs. The added permanent-denial tests only model stat failing too, so they do not cover this reachable permission layout.

  } else if (age > staleMs) {
    try {
      fs.unlinkSync(g);
      continue;
    } catch (unlinkError) {
      if (timedOut) throw unlinkError;
    }
  } else if (timedOut) throw timedOutError();
  

  Also add a regression test where openSync(..., 'wx') and unlinkSync return EACCES while statSync returns an old mtime, asserting termination and the access error.

What's good: the rework correctly distinguishes ENOENT from other stat failures, bounds the vanishing-guard path, and adds focused injected coverage. All reported CI checks, including both Windows Node versions, are green.

[sprayberry-redline]

Automated review from the Sprayberry Labs fleet code reviewer.
Reviewed by the GPT gating lane (gating review).

Verdict: approve — no blocking issues found in the live-head rework.

The rework at 27ca620dc45f2e23e241eea704424474f2ba506e closes the prior stale-guard unlink failure: src/lock.mjs:155-166 now retains the retry window for a transient failure but throws the actual unlinkSync access error once the deadline expires. test/lock-guard-windows.test.mjs:129-175 specifically models the reachable layout where guard metadata is readable but open(wx) and unlink return EACCES/EPERM, and asserts termination with that access error.

What's good: the change is narrowly scoped to the reported unbounded-loop path and preserves the Windows delete-pending retry behavior. The complete CI matrix is green, including Windows on Node 20 and 22; I did not run the local suite.