@mjasnikovs/pi-task 0.38.9 → 0.38.10

package/dist/workers/research-cache.d.ts

@@ -1,5 +1,7 @@
 /** The env var the orchestrator stamps with the per-run id children inherit. */
 export declare const RESEARCH_RUN_ID_ENV = "PI_TASK_RUN_ID";
+/** Is this a transient filesystem error worth retrying inside the caller's deadline? */
+export declare function isRetryableFsError(err: unknown): boolean;
 export declare function researchCacheFile(cwd: string): string;
 /**
  * The current run's id, or undefined when caching is off (the orchestrator did not

package/dist/workers/research-cache.js

@@ -117,6 +117,12 @@ const LOCK_SUFFIX = '.lock';
 const LOCK_TIMEOUT_MS = 2_000;
 /** Poll interval while the lock is held by someone else. */
 const LOCK_POLL_MS = 10;
+/**
+ * How long the atomic replace retries a transient refusal. Short: the lock is HELD for
+ * every one of these milliseconds, so this trades a bounded stall for not losing a
+ * write the lock was taken to protect.
+ */
+const RENAME_TIMEOUT_MS = 500;
 /**
  * A lock older than this is treated as abandoned and removed. Two writers can both
  * decide that and both proceed, which degrades exactly to the pre-lock behaviour (one
@@ -124,6 +130,32 @@ const LOCK_POLL_MS = 10;
  * the run. Sized far above the critical section, so a live holder is never stolen from.
  */
 const LOCK_STALE_MS = 30_000;
+/**
+ * Filesystem errors that mean "try again in a moment", not "this will never work".
+ *
+ * POSIX gives `mkdir` two clean answers when someone else holds the lock: it succeeds,
+ * or it is EEXIST. Windows has a third. A directory that another process is removing
+ * enters a DELETE-PENDING state, and a create against it fails with EPERM/EACCES/EBUSY
+ * instead of EEXIST — so the exact moment the previous writer released the lock is a
+ * window in which the next writer's `mkdir` fails with a code that used to be read as
+ * fatal. The store was then silently skipped: no throw, no log, exit code 0, one entry
+ * missing. That is the whole of CI's `39 of 40` on windows-latest; the same run's
+ * ubuntu half is green because POSIX never produces the code.
+ *
+ * `rename` over an existing file has the same shape on Windows — it fails while any
+ * other handle is open on the target, including a scanner's — so the cache write
+ * retries on this set too.
+ */
+const RETRYABLE_FS_CODES = new Set(['EEXIST', 'EPERM', 'EACCES', 'EBUSY', 'ENOTEMPTY']);
+/** Is this a transient filesystem error worth retrying inside the caller's deadline? */
+export function isRetryableFsError(err) {
+    const code = err?.code;
+    return code !== undefined && RETRYABLE_FS_CODES.has(code);
+}
+/** Does this error mean the lock directory is genuinely held right now? */
+function isHeldError(err) {
+    return err?.code === 'EEXIST';
+}
 /**
  * Schema marker for per-entry package provenance. A file without it was written by a
  * version that stored no `pkg` on its entries, so its docs entries are indistinguishable
@@ -307,15 +339,35 @@ export async function lookupResearch(cwd, runId, key) {
 }
 /** Write the cache file atomic-ish, so a concurrent reader never sees it half-written. */
 async function writeCacheFile(cwd, out) {
+    const tmp = `${researchCacheFile(cwd)}.${process.pid}.${Math.random().toString(36).slice(2, 8)}.tmp`;
     try {
         await fsp.mkdir(tasksDir(cwd), { recursive: true });
-        const tmp = `${researchCacheFile(cwd)}.${process.pid}.${Math.random().toString(36).slice(2, 8)}.tmp`;
         await fsp.writeFile(tmp, JSON.stringify(out), 'utf8');
-        await fsp.rename(tmp, researchCacheFile(cwd));
+        // The replace, not the write, is the part Windows can transiently refuse — any
+        // other open handle on the target (a reader, a scanner) fails it with EPERM.
+        // The whole point of the lock above is that this write is not lost, so a
+        // transient refusal is retried inside the same bounded budget rather than
+        // swallowed. The lock is still held throughout.
+        const deadline = Date.now() + RENAME_TIMEOUT_MS;
+        for (;;) {
+            try {
+                await fsp.rename(tmp, researchCacheFile(cwd));
+                return;
+            }
+            catch (err) {
+                if (!isRetryableFsError(err) || Date.now() >= deadline)
+                    throw err;
+                await new Promise(resolve => setTimeout(resolve, LOCK_POLL_MS));
+            }
+        }
     }
     catch {
         // best-effort cache
     }
+    finally {
+        // Never leave a .tmp behind for a replace that never happened.
+        await fsp.rm(tmp, { force: true }).catch(() => { });
+    }
 }
 /**
  * Serialises this process's own writers per cache file, so the 4-6 parallel tool calls
@@ -337,8 +389,18 @@ async function acquireLock(lockPath, deadline) {
             return true;
         }
         catch (err) {
-            if (err.code !== 'EEXIST')
+            if (!isRetryableFsError(err))
                 return false;
+            // Not EEXIST but still retryable ⇒ Windows delete-pending (see
+            // RETRYABLE_FS_CODES). There is no lock to inspect for staleness: the
+            // directory is on its way out, so wait one poll and try to create it again
+            // rather than reporting a hold that nobody has.
+            if (!isHeldError(err)) {
+                if (Date.now() >= deadline)
+                    return false;
+                await new Promise(resolve => setTimeout(resolve, LOCK_POLL_MS));
+                continue;
+            }
             try {
                 const st = await fsp.stat(lockPath);
                 if (Date.now() - st.mtimeMs > LOCK_STALE_MS) {

package/package.json

@@ -1,6 +1,6 @@
 {
     "name": "@mjasnikovs/pi-task",
-    "version": "0.38.9",
+    "version": "0.38.10",
     "description": "Deterministic task planning and spec-orchestration for local models — crash-safe /task pipelines with verify/enforce gates, a real-time remote web view, and web/docs/fetch/worker subagent tools.",
     "type": "module",
     "main": "./dist/index.js",