From 818aaf2542aae84644e7eb6a9fb34e09e273b198 Mon Sep 17 00:00:00 2001
From: Ross Gardler <250240+SorraTheOrc@users.noreply.github.com>
Date: Fri, 22 May 2026 20:12:39 +0100
Subject: [PATCH] WL-0MPFGDDZ3009J2P4: Fix corrupted lock cleanup grace window
 scaling with exponential backoff

The grace window for unparseable/corrupted lock files was calculated as
Math.max(currentDelay * 2, 500), where currentDelay grows with exponential
backoff on each retry. This caused the grace window to keep pace with file
age, preventing corrupted lock cleanup within the default 5000ms timeout.

Fix: use a fixed 1000ms grace window instead of scaling with retry delay.
This is safe because lock file writes (open, write, fsync, close) complete
in <100ms, so 1000ms is more than adequate to guard against concurrent
writers, while ensuring corrupted files are recovered deterministically
within ~1 second.
---
 src/file-lock.ts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/file-lock.ts b/src/file-lock.ts
index 05be22b5..5f6ae57c 100644
--- a/src/file-lock.ts
+++ b/src/file-lock.ts
@@ -337,7 +337,7 @@ export function acquireFileLock(lockPath: string, options?: FileLockOptions): vo
           try {
             const stat = fs.statSync(lockPath);
             const fileAge = Date.now() - stat.mtimeMs;
-            const graceMs = Math.max(currentDelay * 2, 500);
+            const graceMs = 1000;
             if (fileAge > graceMs) {
               debugLog(`Stale lock detected: corrupted lock file (age ${Math.round(fileAge)}ms > grace ${graceMs}ms), removing ${lockPath}`);
               try {