fencing tokens

[ORESoftware]

do we need them like Redis does?

Key Points in the Addendum
Vercel KV (Upstash Redis, now sunset) never provided native fencing tokens — only raw SET NX, GET, DEL primitives
SyncGuard (Oct 2025) bolts fencing tokens onto single-node Redis via atomic INCR + Lua scripts — no Redlock needed
You can have fencing tokens without Redlock (single Redis INCR + cooperative storage) and Redlock without fencing tokens (quorum lock but no zombie protection) — they're orthogonal
The practical takeaway: fencing tokens on a single Redis node give you more correctness than Redlock on 5 nodes without fencing tokens

[ORESoftware]

Yes, live-mutex would benefit from optional fencing tokens, but only for callers that can enforce them downstream.

A lock prevents concurrent entry while the broker believes the lock is valid. A fencing token protects against the zombie case:

A gets lock, token 41
A stalls / loses connection / TTL expires
B gets lock, token 42
B writes successfully
A wakes up and tries to write with token 41
storage rejects token 41

That is the key distinction. Fencing tokens do not make the broker “more locked”; they make stale lockholders harmless when the guarded resource checks monotonically increasing tokens. Kleppmann’s classic critique frames fencing as the fix for clients that continue work after their lease expired. ([Martin Kleppmann]1) Redis’s own distributed-lock docs now also say fencing tokens should be implemented for long-running processes. ([Redis]2)

For live-mutex specifically, this fits well because it already uses a single broker as the source of truth for lock state. ([GitHub]3) The broker can maintain:

fenceCounters: Map<lockKey, bigint>

and return a token on successful acquisition:

const { unlock, fence } = await client.lock('user1');

For multi-locks:

const { unlock, fences } = await client.lockMany([
  'user1',
  'writeFavoritesForUser1'
]);

// fences:
// {
//   user1: 103n,
//   writeFavoritesForUser1: 58n
// }

For convenience, it could also return a single aggregate token:

fence = max(fences)

but per-key tokens are more correct if each protected resource tracks its own latest token.

The important caveat: fencing only works if the actual resource cooperates. For example, a database row/table/object needs something like:

UPDATE favorites
SET value = ?, last_fence = ?
WHERE user_id = ?
  AND ? > last_fence;

Without that downstream check, the token is just metadata.

So my take:

Yes, add fencing tokens.
Make them optional and backward-compatible. They are especially useful for TTL expiry, paused Node processes, network blips, broker reconnects, and multi-lock operations.

But don’t market them as a complete correctness guarantee unless the README clearly says: “The protected storage/resource must reject stale fencing tokens.” SyncGuard’s docs say the same core thing: fencing lets the backend reject stale operations after a lockholder has unknowingly lost the lock. ([kriasoft.com]4)