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

retrymq limit & DLQ

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

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

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

Línea de trabajo

Start by locating the retry task executor and the queue handling that uses receive count and the 30-second visibility timeout; compare its configuration with deliverymq. Resolve the open questions about the receive limit, backoff, DLQ behavior, and configuration before implementation. Done means repeated internal failures are capped and stuck messages can be surfaced or replayed, with behavior configurable as agreed.

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

Descripción

When a retry task's executor fails (e.g., event not found in logstore, transient errors), the message sits in the queue and becomes visible again after a fixed 30s visibility timeout. This repeats indefinitely with no limit.

Problems

  • A permanently failing retry message cycles forever with no cap
  • No dead-letter path to detect or surface stuck messages
  • Fixed visibility timeout on re-fetch failures — no backoff between attempts

The underlying queue already tracks receive count and supports per-message visibility changes, so the primitives are there.

Open questions

Max receive count

What should the default be?

Suggestion: 5 internal re-fetch attempts before giving up. This is separate from the delivery retry max limit, which controls how many times we re-deliver to the destination.

Backoff on re-fetch

Should we apply exponential backoff on internal failures (e.g., 30s → 60s → 120s), or is a fixed interval fine since these are typically short-lived transient issues?

What happens when max is exceeded

Suggestion: Route to a DLQ. Gives observability into stuck messages and the ability to replay them.

Configuration

Suggestion: Expose as retrymq config, similar to how deliverymq is configured. e.g., RETRYMQ_MAX_RECEIVE_COUNT, RETRYMQ_VISIBILITY_TIMEOUT_SECONDS.

Lenguaje dominante
Go
Estrellas
1.1k
Forks
70
Merge medio
1 d 19 h
PR fusionados (30 d)
54

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 hookdeck/outpost

Todos los issues de hookdeck/outpost

Issues similares

Más issues de Go

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.