ZombieMutex

30 results · ↑ ↓ navigate · Enter open · Esc close

All writing
Engineering#Authentication#Mobile Security#Backend#Concurrency#Session Recovery#Reproducible Tests
November 6, 20262 min read

Refresh-token rotation under concurrent replay: 200 scheduled callers

A reproducible local test of one-use token families, revocation and expiry, with the exact limits of a single-process model.

By

Share

Send this post or copy the direct link.

Suggest a correction

A refresh credential is supposed to be consumed and rotated when it is used. What happens when two callers present it before the backend records the first rotation?

A small reference test harness was developed to expose this question in a controlled setting. Its public source is ZombieMutex Session Rotation. The implementation uses SHA-256 digests of high-entropy random token bytes and tracks active, consumed, expired and revoked state for one token family.

This is not a production session server, signed JWT issuer or example of working with real customer credentials.

Test setup

One local session family begins with a single valid refresh token. The test schedules 200 Promise callbacks, each attempting to rotate the same token.

text
git clone https://github.com/DeadPineapple/zombiemutex-session-rotation.git
cd zombiemutex-session-rotation
npm test

The important assertion is simple:

typescript
const replies = await Promise.all(
  Array.from({length: 200}, () =>
    Promise.resolve().then(() => service.rotate("alice", token))
  )
);

assert.equal(replies.filter(reply => reply.ok).length, 1);

Observed local outcomes

ConditionLocal test observation
200 scheduled uses of one tokenOne successor accepted
Reuse of consumed tokenRejected as replay
Explicit family revocationBlocks active and previously used credentials
Expired family tokenRotation denied
Duplicate family creationRejected

Five repository tests passed under Node.js 24.21 on macOS. These are reproducible logical outcomes, not evidence of cross-region atomicity or hardened production account recovery.

The trust boundary

The code runs within one process. Synchronous consume-and-replace operations are serialized by the JavaScript runtime, so the test is intentionally incapable of reproducing a database-level lost-update race across two independent server processes. Treat its result as an assertion about a local state machine, not a service-level availability or security guarantee.

Real production token families require durable atomic updates, expiration and key lifecycle handling, issuer/audience validation where relevant, explicit theft-detection policy, service-wide revocation, and protected recovery flows. Do not log raw refresh tokens or accept client-reported session state as authorization.

The interactive session recovery lab lets a reader share a specific synthetic event sequence. The deeper session state-machine guide covers the recovery bypasses a simple rotate function does not address.


Provenance: A new AI-assisted reference project with actual local tests. It does not claim to represent an existing real-world account service, security certification or personal employment accomplishment.

Related technical notes with overlapping topics.