@zerotal/cache 1.4.0 → 1.5.0

package/CHANGELOG.md

@@ -8,6 +8,18 @@ follows the Zerotal monorepo's unified versioning.
 
 ## [Unreleased]
 
+## [1.5.0] — 2026-08-15
+
+### Fixed
+
+- **Stampede protection survives a compute slower than 30 seconds.** `remember()`'s
+  recompute lock had a fixed 30s TTL and no way to extend it, so a factory that ran longer
+  silently dropped its lock and let a second node in — and an expensive query is the only
+  kind anyone bothers caching, so the protection failed precisely where it was needed. The
+  lock now refreshes for as long as the factory runs. A lock lost anyway falls back to
+  re-checking the cache and recomputing, which is what a timed-out waiter already did:
+  caching is best-effort here, not a correctness boundary.
+
 ## [1.0.3] — 2026-08-07
 
 ### Changed

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@zerotal/cache",
-  "version": "1.4.0",
+  "version": "1.5.0",
   "license": "MIT",
   "maturity": "stable",
   "private": false,
@@ -30,7 +30,7 @@
     "typecheck": "tsc --noEmit"
   },
   "dependencies": {
-    "@zerotal/core": "1.4.0"
+    "@zerotal/core": "1.5.0"
   },
   "devDependencies": {
     "typescript": "^5.8.0"

package/src/CacheManager.ts

@@ -3,10 +3,16 @@ import { CacheSerializationError, CacheDeserializationError } from "./errors.ts"
 import { FrameworkEvents, sha256Hex } from "@zerotal/core";
 import { CacheQueried } from "./events.ts";
 import type { LockManager } from "@zerotal/core/lock";
-import { LockNotAcquiredError } from "@zerotal/core/lock";
+import { LockNotAcquiredError, LockLostError } from "@zerotal/core/lock";
 
 // Cross-process recompute lock for remember(): how long the lock is held while the
 // factory runs, and how long a waiter blocks for the holder before recomputing anyway.
+//
+// The TTL is now a heartbeat interval rather than a deadline — the lock is
+// refreshed for as long as the factory runs, so a compute slower than 30s no
+// longer silently drops its lock and lets a second node in. That was the exact
+// case where stampede protection stopped protecting: an expensive query, which
+// is the only kind anyone bothers caching.
 const STAMPEDE_LOCK_TTL = 30; // seconds
 const STAMPEDE_LOCK_WAIT = 30; // seconds
 
@@ -137,9 +143,15 @@ export class CacheManager {
       return await this._lock.block(lockKey, STAMPEDE_LOCK_TTL, recheckThenCompute, {
         timeout: STAMPEDE_LOCK_WAIT,
         retryDelay: 50,
+        refresh: true,
       });
     } catch (err) {
       if (err instanceof LockNotAcquiredError) return recheckThenCompute();
+      // A lost lock is not a reason to fail the read. Caching is best-effort by
+      // design here — a waiter that times out already recomputes — so losing the
+      // lock mid-compute means at worst two nodes did the work, which is the
+      // thing we were optimising, not a correctness boundary.
+      if (err instanceof LockLostError) return recheckThenCompute();
       throw err;
     }
   }