Dead-letter queue

Inspect, retry, and purge jobs that exhausted their retries.

When a job exhausts its retries it moves to the dead-letter queue (DLQ) and the DEAD event fires. The DLQ keeps the payload and error history so you can investigate and replay.

Coming from JMS/RabbitMQ?

There's no separate DLQ/DLX to declare, bind, or point a routing key at — flexiq's dead-letter store is built into the same client and queried through the same API (listDead, retryDead) as everything else.

java

List<DeadJob> dead = queue.listDead(50, 0);        // newest first, paged
List<DeadJob> charges = queue.listDeadByTask("charge", 50, 0);
String newJobId = queue.retryDead(deadId);         // re-enqueue (preserves metadata)
queue.deleteDead(deadId);                          // drop one entry
long dropped = queue.purgeDead(olderThanMs);       // bulk-drop entries older than a cutoff
long removed = queue.purgeDeadByTask("charge");    // drop every entry for one task

Each DeadJob records the original job id, queue, task name, final error, retry count, failure time, metadata, and how many times it has been replayed from the DLQ (dlqRetryCount). Inspect why a job failed attempt by attempt:

java

List<JobError> history = queue.jobErrors(dead.originalJobId);

From the CLI:

bash

flexiq --url flexiq.db dlq list
flexiq --url flexiq.db dlq retry <deadId>
flexiq --url flexiq.db dlq delete <deadId>

A retried dead job re-enters as PENDING with a fresh retry budget. Metadata survives the DLQ round-trip, so context attached at enqueue is preserved through replay.