Xconfess/Xconfess
[Wave 6] Add DLQ replay/requeue mechanism for failed notification jobs
Ouverte
#1 663 ouverte le 28 juil. 2026
Backendhelp wantedreliability
Métriques du dépôt
- Stars
- (14 étoiles)
- Métriques de merge PR
- (Métriques PR en attente)
Description
Problem
Failed notification jobs land in the Redis-backed dead-letter queue and are visible in the admin DLQ table (see #1000 for the UI states), but there is no backend mechanism to actually requeue or replay them. Ops has to manually re-trigger the originating event.
Tasks
- Add a backend endpoint (admin-guarded) to requeue a single DLQ entry or a batch by job type
- Add a max-replay-attempts guard so a poison message can't loop forever
- Emit an audit log entry for every manual replay (who, when, job id)
- CLI script under scripts/ for ops to replay from the command line without going through the UI
Acceptance Criteria
- Replaying a DLQ entry re-enters the original queue with the same payload and an incremented replay counter
- Exceeding max replay attempts moves the entry to a permanently-failed state instead of looping
- e2e test: force a notification job to fail, confirm it lands in DLQ, replay it, confirm success
Labels
Backend, reliability, help wanted, Stellar Wave