Skip to content

Add atomic Redis lock acquisition to prevent race conditions in DistributedLockService #888

Description

@RUKAYAT-CODER

Overview

src/orchestration/locks/distributed-lock.service.ts acquireLock() may use a non-atomic check-then-set pattern. If acquisition uses separate GET + conditional SET commands, two callers can both read "no lock" and both proceed to set, creating a race condition. Lock acquisition must use Redis SET NX PX in a single atomic command.

Specifications

Features:

  • Lock acquisition must use a single atomic SET key value NX PX ttl command.
  • Return false immediately if the lock is already held (non-blocking) or implement configurable retry with timeout.

Tasks:

  • Replace any multi-command acquisition with redis.set(key, token, 'PX', ttlMs, 'NX').
  • Return the unique token if acquired, null if not.
  • Add a withLock(key, ttl, fn) helper that acquires, runs fn, and always releases.
  • Add load tests proving at most one caller holds the lock at any moment.

Impacted Files:

  • src/orchestration/locks/distributed-lock.service.ts

Acceptance Criteria

  • Under 100 concurrent acquireLock calls, exactly one caller succeeds.
  • SET NX PX is used as a single Redis command (verified via spy in unit tests).
  • withLock helper releases the lock even if fn throws.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Stellar WaveIssues in the Stellar wave programbugSomething isn't workingsecurity

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions