Skip to content

[P0-23] Implement the initial Valkey target-lease backend with atomic fencing scripts #31

Description

@lost-rob0t

Decision

Use Valkey as the first deployable KV backend behind the lease-store protocol. Keep the protocol backend-neutral so a stronger-consistency backend can be added without changing target or HTTP code.

Required implementation

  • One atomic acquire script: create lease only when free/expired and increment a monotonic fencing counter.
  • Atomic renew script requiring matching lease id, owner, and fencing token.
  • Atomic compare-and-delete release.
  • TTL stored by the backend; server time/TTL result is authoritative.
  • Request-id result cache for idempotent retries.
  • Namespaced keys suitable for standalone and clustered deployments.
  • Connection pooling, authentication, TLS configuration, deadlines, reconnect/backoff, and health checks.
  • No use of unsafe GET then SET races.
  • Document failover/replication assumptions and where fencing is enforced downstream.

Acceptance tests

  • Backend contract suite passes against a real Valkey service.
  • 100 concurrent acquire attempts yield one owner and one fencing token generation.
  • Expiry followed by reacquire produces a strictly larger token.
  • Old owner cannot renew, release, or commit after reacquire.
  • Script interruption/retry is idempotent by request id.
  • Credentials and lease metadata are redacted from logs where required.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions