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

JobSnooze accepts negative durations despite documented panic contract

Abierto Apto para principiantes
  • ¿Algo no está bien?
#1,454 1 comentario 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
2/5
Tiempo estimado
1-3 horas
Aptitud para principiantes
72/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
go
Área
backend

Línea de trabajo

Comienza en error.go, donde se definen el constructor JobSnooze y su JobSnoozeError; el issue enlaza las líneas exactas (L30-L45) y señala la falta de una guarda para duraciones negativas. Revisa cómo internal/jobexecutor/job_executor.go consume los errores de snooze antes de escribir la guarda, y confirma el contrato pretendido en el hilo del issue antes de cambiar el comportamiento. Listo significa que JobSnooze(-duration) produce un panic, mientras que las duraciones cero y positivas siguen devolviendo *river.JobSnoozeError, verificado mediante un test enfocado al estilo del proporcionado, ejecutado con go test -race en los paquetes afectados.

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

Descripción

Problem

JobSnooze documents that it panics when duration < 0, but currently returns a JobSnoozeError with the negative duration instead.

At current default commit ba85f3e01faf0db172882e377e87aabf4f2f07cb, error.go has no negative-duration check. The executor handles snooze errors before normal error/max-attempt handling, computes now + duration, and decrements the attempt count. A negative duration therefore follows the immediate-availability branch rather than the documented validation failure. I have traced that branch but have not run a database-backed execution test.

Reproduction and evidence

A public-API test expecting a panic for JobSnooze(-time.Nanosecond) and JobSnooze(-time.Second) fails in both cases. Controls for JobSnooze(0) and JobSnooze(time.Second) pass and preserve the duration via errors.As to *river.JobSnoozeError.

func TestJobSnoozeRejectsNegativeDuration(t *testing.T) {
    t.Parallel()

    defer func() {
        if recover() == nil {
            t.Fatal("expected JobSnooze to panic for a negative duration")
        }
    }()
    _ = river.JobSnooze(-time.Nanosecond)
}

The isolated test ran with Go 1.27.1 and -race -count=1, without a database, Client.Start, or network access. The module version was v0.48.1-0.20261004195309-6cdaf386c3f6. I separately checked that the module's error.go, internal/jobexecutor/job_executor.go, and internal/jobexecutor/job_executor_test.go blobs exactly match the current default commit. This is narrow API reproduction, not a claim that the full current workspace test suite passes.

Merged #1037 explicitly supports zero-duration snoozes and retained the negative-duration panic documentation. Existing executor tests cover scheduled and immediately available snoozes; I did not find a negative-duration constructor test or an existing matching issue/PR in the targeted search.

Proposed scope

Is the documented negative-duration panic still the intended contract? If so, I can add the constructor guard and focused regression tests while preserving zero/positive durations. If negative durations are intentionally equivalent to zero, I would appreciate confirmation before changing behavior; the documentation would need to reflect that instead.

This is separate from the worker-registration atomicity question in #1433. No production code, protocol, database schema, or retry policy has been changed. Investigation and synthetic tests were assisted by OpenAI Codex; the reported results are actual local executions.

Lenguaje dominante
Go
Estrellas
5.8k
Forks
188
Merge medio
22 h 44 min
PR fusionados (30 d)
95

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 riverqueue/river

Todos los issues de riverqueue/river

Issues similares

Más issues de Go

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.