Race Conditions in Idempotency-Key Deduplication Logic

Analyzing concurrent HTTP requests and time-of-check to time-of-use (TOCTOU) flaws in distributed idempotency implementations.

Introduction

Idempotency keys prevent duplicate payments and operations when network retries occur. Standard RFC specifications suggest caching the idempotency key and returning the cached response if repeated within a given TTL window.

The Concurrency Window

When a naive implementation uses standard multi-step cache checks:

python

# Vulnerable Pattern
def process_order(idempotency_key, payload):
    cached = redis.get(f"idempotency:{idempotency_key}")
    if cached:
        return json.loads(cached)
    
    # 10ms execution gap
    result = execute_payment(payload)
    
    redis.set(f"idempotency:{idempotency_key}", json.dumps(result), ex=3600)
    return result

If two identical requests arrive within 10ms of each other, both evaluate `cached == None`. Both dispatch payment transactions to the bank.

Solution

Use atomic lock acquisition or Redis `SET key value NX EX` prior to executing any state-altering logic:

python

# Hardened Atomic Pattern
def process_order(idempotency_key, payload):
    lock_acquired = redis.set(f"lock:{idempotency_key}", "processing", nx=True, ex=30)
    if not lock_acquired:
        raise ConcurrencyConflictException("Request is already in flight.")
    
    try:
        result = execute_payment(payload)
        redis.set(f"result:{idempotency_key}", json.dumps(result), ex=3600)
        return result
    finally:
        redis.delete(f"lock:{idempotency_key}")

#Race Condition

#Idempotency

#Concurrency

#Redis