Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

[Suggestion] Move jobs between queues, change the job body, custom metadata for a better failure handling

Abierto
  • ¿Algo no está bien?
#174 2 comentarios 0 reacciones 0 asignados Ver en GitHub

@mathieulongtin ya está trabajando en esto.

Desde el 28/2/2016.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
20/100
Tipo de issue
Nueva funcionalidad
Claridad
Necesita aclaración
Estado de actividad
Estancado
Stack tecnológico
c
Área
distributed-systems

Línea de trabajo

Comienza revisando la discusión relacionada en #170 y el manejo actual de los trabajos fallidos descrito en este issue. Aclara cuál de las cuatro propuestas superpuestas se desea y, a continuación, define la API, el comportamiento de la identidad y los metadatos del trabajo, y los criterios de aceptación para conservar los IDs y los detalles de los reintentos.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Hi,
this suggestion is connected to #170 in that both concern the handling of failed jobs.

I would like to handle failed jobs as follows:

  • NACK the failed job with an ever growing delay (#170)
  • If the number of retries is higher than X, move the job to a failure queue (dead letter queue) with a new TTL, so that it can be inspected manually and acted upon

Neither of these actions are possible in Disque right now and if using a workaround - adding a new, copied job - we lose both the job ID as well as the NACK and add. delivery counters.

That's why I would like to propose four enhancements (proposals 3. and 4. are different solutions of the same problem):

  1. Allow to NACK a job with a delay (#170)
  2. Allow to move a job to a different queue with a new TTL
  3. Allow callers to change the job body
  4. OR even better, if feasible: Implement custom job metadata support, like NACKs and additional-deliveries but user-defined and mutable

Ad 3. We use the job body to store job metadata. We use metadata to work around missing features 1. and 2. - we store the original job ID as well as the total number of retries there. It could also be helpful to eg. save the exact time and reason the job has failed. This requires changing the existing job body.
Supporting custom, mutable job metadata as a first class citizen in Disque would be even better.

The point of all these suggestions is to keep the ID of a job intact throughout its lifetime while allowing for a more complex handling (delayed NACKing, moving between queues, storing extra details).

What do you think? Are the suggestions too complex? Are they useful?

Lenguaje dominante
C
Estrellas
8.1k
Forks
532
Sin PR fusionados en 30 d

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de antirez/disque

Todos los issues de antirez/disque

Issues similares

Más issues de C

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.