- Duplicate client retry: the idempotency-key unique constraint returns the original database job and prevents a second queue message.
- Worker exception: BullMQ retries with exponential backoff; PostgreSQL records the latest concise error.
- Stalled operation: the worker timeout rejects the operation so retry policy can take over.
- Final failure: the durable state becomes
FAILED, retaining the attempt count and last error. - Manual replay: only failed jobs can be replayed. A unique queue-message id is used while the durable database id remains stable.
- Redis retention: completed and failed BullMQ records are bounded. PostgreSQL remains the audit and status source.
For production, the next steps would be a dead-letter dashboard, OpenTelemetry traces, leader-safe scheduled recovery for orphaned RUNNING rows, and tenant-level rate limits.