ZombieMutex

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

Featured engineering / Inspect the evidence

Source, tests, diagrams. Not just claims.

Three original, AI-assisted teaching projects with independently runnable tests, actual screenshots from the related browser labs, specific failure cases and their limits. This is public reference code—not customer software or audited production infrastructure.

16 tests passing across three repositoriesBrowse the build log
01

One-time challenge replay guard

A local challenge guard that binds principal, action and expiry to one consume decision.

Actual screenshot of the ZombieMutex one-time challenge browser lab; a synthetic educational interface
Genuine screenshot of the live browser teaching lab, captured November 5, 2026. Not a client app screenshot.

Reproduced test observations

1 successful consume and 199 replay rejections among 200 Promise-scheduled attempts; 5 of 5 tests passed.

npm test · 5/5 passed

Scheduled calls are test assertions, not throughput benchmarks.

Failure cases and limitations

An action or principal mismatch is rejected; expired challenges and reused challenges are rejected.

This uses one process and an in-memory map. It does not perform Apple App Attest, Google Play Integrity, durable distributed claims, or network transactions.

Architecture and trust boundaries

  1. Client-controlled input

    1. Client request

    Presents one-time challenge, principal and action.

  2. Local server decision

    2. Binding check

    Compare requested action and principal with minted context.

  3. Single-process simulation

    3. Atomic local consume

    Synchronously claim the token in one JavaScript process.

  4. Local server decision

    4. Decision

    First caller accepts; later/replayed attempts fail.

Diagram of the tested reference model, not a production architecture or telemetry trace. Client inputs remain untrusted even when an integrity signal is valid.
02

Idempotency under concurrent requests

Tenant-scoped operation keys, matching request fingerprints and a shared effect callback.

Actual screenshot of the ZombieMutex API retry browser lab; synthetic HTTP retry scenarios
Genuine screenshot of the live browser teaching lab, captured November 5, 2026. Not a client app screenshot.

Reproduced test observations

1 side-effect callback across 100 concurrent scheduled requests; all 6 of 6 tests passed.

npm test · 6/6 passed

Scheduled calls are test assertions, not throughput benchmarks.

Failure cases and limitations

Mismatched payload fingerprint is rejected; tenants remain isolated; uncertain responses stay retained during the key window.

In-process Promise scheduling is not a distributed exactly-once guarantee. No live database transaction, external payment provider or worker crash is tested.

Architecture and trust boundaries

  1. Client-controlled input

    1. API callers

    100 calls reuse one tenant and idempotency key.

  2. Local server decision

    2. Fingerprint

    Check tenant, operation and canonical request intent.

  3. Single-process simulation

    3. Local claim

    One promise path owns the side-effect callback.

  4. Local server decision

    4. Result replay

    Return the retained outcome to duplicate requests.

Diagram of the tested reference model, not a production architecture or telemetry trace. Client inputs remain untrusted even when an integrity signal is valid.
03

Refresh-token rotation under replay

Single-use refresh credentials with token-family generation, revocation and expiry.

Actual screenshot of the ZombieMutex session recovery lab; educational state-machine interface
Genuine screenshot of the live browser teaching lab, captured November 5, 2026. Not a client app screenshot.

Reproduced test observations

1 successor credential issued from 200 presentations of the same refresh token; all 5 of 5 tests passed.

npm test · 5/5 passed

Scheduled calls are test assertions, not throughput benchmarks.

Failure cases and limitations

Already-consumed tokens, revoked families, expired credentials and malformed inputs are rejected.

A single in-memory token family is not a production identity service. Multi-process atomic rotation, storage persistence and operational recovery need separate testing.

Architecture and trust boundaries

  1. Client-controlled input

    1. Refresh caller

    Presents a bearer refresh credential.

  2. Local server decision

    2. Family validation

    Check generation, expiry, active family and revocation.

  3. Single-process simulation

    3. Consume old token

    Local synchronous one-time state transition.

  4. Local server decision

    4. Issue successor

    Exactly one new generation; replay attempts fail.

Diagram of the tested reference model, not a production architecture or telemetry trace. Client inputs remain untrusted even when an integrity signal is valid.

What this evidence does—and doesn't—show

All three public repositories passed fresh local Node test runs on November 5, 2026. Their concurrency tests use scheduled promises in one process; they do not establish cross-worker atomicity, production authorization correctness, or platform attestation verification. Screenshots show the related site labs, not external production deployments. No fabricated customer screenshots, incidents or performance metrics are used.

See the complete evidence policy →