Skip to content
Code Recycle

Component · for humans & their agents

Queue Lease Semantics

verified · first-partyactively maintained$0 during beta (was $69)

Every mainstream queue is at-least-once. Almost every consumer is written as though it were exactly-once. Nothing throws.

by ringbuffer · Code Recycle admin

Get it free — beta

Every claim on this page is refundable if it is untrue — refund policy.

Verified: 80 tests · 1 adversarial review · verified by an independent reviewer, not the author

A broker-agnostic lease manager for at-least-once message queues -- SQS, Pub/Sub, Service Bus, Redis Streams, and anything shaped like them. It does not talk to a queue: you hand it the lease facts your broker SDK already returned plus an injected clock, and it hands back typed decisions with reasons.

A broker-agnostic lease manager for at-least-once message queues -- SQS, Pub/Sub, Service Bus, Redis Streams, and anything shaped like them. It does not talk to a queue: you hand it the lease facts your broker SDK already returned plus an injected clock, and it hands back typed decisions with reasons.

THE SILENT FAILURE. Four failures, none of which throw. All four are indistinguishable from success in your logs, your dashboards and your queue-depth graph. The only trace is in the effects: a customer charged twice, an email sent twice, a counter incremented twice.

VISIBILITY TIMEOUT SHORTER THAN THE WORK. The message becomes visible again while the first worker is still processing it, a second worker picks it up, and the job runs TWICE CONCURRENTLY. Both workers report success, because from each worker's point of view nothing went wrong.

ACKING AN EXPIRED LEASE. The first worker finishes late and deletes the message with a receipt handle from a lease that already expired -- acknowledging a delivery that is no longer its own. In some brokers that removes work another worker is midway through.

THE POISON MESSAGE LOOP. A message that always fails is retried forever. Throughput looks fine, queue depth looks stable, and one message quietly consumes a worker slot permanently.

HEARTBEAT DRIFT. A long job extends its lease on a timer and assumes the extension succeeded. If the broker refuses it -- already redelivered, lock already lost -- and the heartbeat call is a fire-and-forget boolean nobody checks, the worker keeps going believing it holds a lease it lost.

Each becomes a checkable question with a typed answer: isHeld(); an ack()/nack() that is REFUSED rather than silently accepted once a lease has expired; an extend() that cannot be mistaken for success because there is no boolean to ignore; a classifyDelivery() that names why a redelivery is happening; and a checkVisibilityTimeoutSafety() that turns 'is my timeout big enough' into an actual number before you ship rather than an incident after.

VERIFIED: 80 tests, re-measured by running the suite. Every mutation was observed FAILING before the source was restored. Independently reviewed by a verifier whose job was to find what is wrong, not to agree.

DELIVERY: signed download of a hash-verified tarball, immediately on purchase. Permissive licence: unlimited products, unlimited clients, unlimited seats, no attribution, perpetual and irrevocable. One restriction, do not republish the source as source.

Interface

What you call, and what comes back. Types and signatures only — the implementation ships with the source.

  export function classifyDelivery(ctx: DeliveryContext): DeliveryClassification;
  export function systemClock(): Clock;
  export function manualClock(startAt = 0): ManualClock;
  export function isDuplicateDelivery( candidateKey: string, seenKeys: ReadonlySet<string> | readonly string[] ): boolean;
  export function checkVisibilityTimeoutSafety( input: VisibilityTimeoutSafetyInput ): VisibilityTimeoutSafetyResult;
  export type PriorOutcome = "timeout" | "nack";
  export type DeliveryClassification = | { kind: "first-attempt";
  export type LeaseStatus = | { state: "held";

01Capabilities

Does

  • + Idempotent fulfilment
  • + Reliability
  • + Queue delivery semantics

Doesn’t

  • No exclusions declared

02Requirements & stack

Depends on

No declared dependencies

Credentials needed

None declared

Stack

typescript

03Community

No endorsements yet

No verified confirmations yet — be the first.

Confirmations come from verified purchasers, installers, vetted reviewers, or an installation outcome your org reported through the agent tools. They grade quality — security is verified separately, and community votes can never override the security gate.

Open an issue

Sign in to confirm — weight comes from verified usage, not vote count.

0 open · 0 answered · 0 fixed · 1 said it worked

04Trust Passport

Full passport →
–/100

0/0 automated components pass. An automated score is never a security guarantee.

✓ Verified · first-partyreviewed Sep 20, 2026 · re-verification due Dec 19, 2026
  • publisher identity Publisher status verified; 1 verification(s) on file
  • malicious pattern scan No known malicious-behavior patterns across 19 source file(s) plus listing text
  • capability contract All 0 observed capability reference(s) match the declared manifest
  • agent safety scan No injection patterns in agent-readable content
  • provenance No release signature or provenance attestation
  • behavioral sandbox Not performed in this environment — requires the production isolated runner (docs/sandbox-requirements.md). No untrusted code is ever executed on the application host.

Every listing must pass this review before it can be sold, and it is re-run on every release. Verification describes what we checked — it is not a guarantee that the software is safe.

VersionChannelReleasedNotes
1.0.0stableAug 5, 2026First public release.