Leases & Redelivery

How DriftQ prevents stuck messages and safely re-delivers work.

When a consumer receives a message, DriftQ marks it in-flight for that owner. That “in-flight” state is protected by a lease.

Goal: avoid stuck messages while still preventing two consumers from doing the same work.

What a lease means

While the lease is active, only the current owner can ack or nack that message.
If another consumer tries to ack/nack the same message with a different owner, DriftQ rejects it (ownership conflict).

Practical effect: leases give you “at-most-one active worker” per message at a time.

Where lease duration comes from

The lease length is determined in this order:

lease_ms on /v1/consume (if provided)
otherwise the broker’s default ack timeout

Rule of thumb: set lease_ms slightly longer than your normal processing time.

Redelivery

If a message isn’t acked before the lease expires, DriftQ assumes the consumer crashed, hung, or lost progress. It then schedules the message for redelivery.

Lease expires → message becomes eligible for redelivery
DriftQ re-queues it for delivery to a consumer
attempts is incremented each time it’s re-delivered

Why attempts matter: they power retry limits and DLQ routing (covered in “Retries & DLQ”).